On Thu, 24 Aug 2023 14:39:18 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:
> I've now realized that the bug had an incorrect statement in the description. > The cycle happens due to the `Runtime.getRuntime().maxMemory()` > implementation in GraalVM to use JDK `Metrics`, since the `ByteBuffer` [code > relies on the `Runtime.getRuntime().maxMemory()` > API](https://github.com/openjdk/jdk/blob/76b9011c9ecb8c0c713a58d034f281ba70d65d4e/src/java.base/share/classes/jdk/internal/misc/VM.java#L261). > The GraalVM impl to use the JDK Metrics seems a reasonable thing to do, no? > > With that said, it's seems a rather uncontroversial change with very limited > scope. Do you see anything problematic in this patch? Happy to revise if you > think there are some no-no's :) Recursive initialization issues can tricky and often it comes down to deciding where to break the cycle. In this case, it seems a bit fragile to do it in CgroupUtil as it should be allowed to use any of the file system APIs to access cgroups or proc files. Part of me wonders if this would be better handled in their implementation of jdk.internal.misc.VM or Runtime.maxMemory but maybe you've been there already? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15416#issuecomment-1693114562
