8314940: Use of NIO in JDKs Metrics implementation causes issues in GraalVM

[jerboaa]

Please review this rather trivial fix to not use nio in CgroupUtil, part of the
JDK's Metrics API. The primary motivating factor is that it allows one to use the
JDK's version of Metrics in GraalVM. See the bug for details as to why this is
needed.

Testing:

• GraalVM builds with/without the fix and the reproducer (fails before/works after)
• jdk/internal/platform jtreg tests on Linux x86_64 (cgv1).
• GHA - passed (Failed GHA cross compile on RISCV is unrelated)

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8314940: Use of NIO in JDKs Metrics implementation causes issues in GraalVM (Bug - P3)

Reviewers

• Thomas Stuefe (@tstuefe - Reviewer)

Contributors

• Aleksandar Pejovic <apejovic@openjdk.org>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15416/head:pull/15416
$ git checkout pull/15416

Update a local copy of the PR:
$ git checkout pull/15416
$ git pull https://git.openjdk.org/jdk.git pull/15416/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 15416

View PR using the GUI difftool:
$ git pr show -t 15416

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15416.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back sgehwolf! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@jerboaa The following label will be automatically applied to this pull request:

• core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[jerboaa]

/cc serviceability-dev

[openjdk]

@jerboaa
The serviceability label was successfully added.

[jerboaa]

/label serviceability-dev

[openjdk]

@jerboaa The serviceability label was already applied.

[mlbridge]

Webrevs

• 00: Full (e470bfcd)

[AlanBateman]

Something fishy here, is this working around a bug in GraaVM native image or why does this change need to be in JDK?

[jerboaa]

Something fishy here, is this working around a bug in GraaVM native image or why does this change need to be in JDK?

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. 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 :)

[jerboaa]

/contributor add pejovica

[openjdk]

@jerboaa pejovica was not found in the census.

Syntax: /contributor (add|remove) [@user | openjdk-user | Full Name <email@address>]. For example:

• /contributor add @openjdk-bot
• /contributor add duke
• /contributor add J. Duke <duke@openjdk.org>

User names can only be used for users in the census associated with this repository. For other contributors you need to supply the full name and email address.

[jerboaa]

/contributor add apejovic

[openjdk]

@jerboaa
Contributor Aleksandar Pejovic <apejovic@openjdk.org> successfully added.

[AlanBateman]

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. 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?

[jerboaa]

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.

In theory, yes. It should be able to use any file system APIs. Practically, it doesn't make a whole lot of difference :-) Going by the last few years this area of the code hasn't had many updates.

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?

Implementing Runtime.maxMemory (determine the configured max heap size), usually needs some notion of 'Physical Memory', since the heap size is being based on 'Physical Memory' if not explicitly set. As with HotSpot, that notion of 'Physical Memory' might depend on whether or not you're running in a container (usually with a single process in that container) or not. The GraalVM implementation uses the JDK cgroups code to figure out the 'Physical Memory' in the container case. I don't think there is a way to implement Runtime.maxMemory without knowing `Physical Memory'.

This isn't a problem in OpenJDK (yet), since HotSpot has its own implementation in its runtime written in C. That has its own set of problems, since we need to update both implementations when bugs come in.

In a way, this boils down to ByteBuffers using max heap size for it's default direct memory size determination. I'm not sure doing something else in GraalVM for determining the default direct memory size would be any better.

All things considered, breaking the cycle in OpenJDK seems reasonable to me. Would this convince you to accept this patch?

[jerboaa]

@AlanBateman Is there anything else you need me to do? If so, please let me know. Thanks!

[tstuefe]

Looks good to me. A comment would be nice, possibly above the imports, warning about using nio.

[openjdk]

@jerboaa This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8314940: Use of NIO in JDKs Metrics implementation causes issues in GraalVM

Co-authored-by: Aleksandar Pejovic <apejovic@openjdk.org>
Reviewed-by: stuefe

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 67 new commits pushed to the master branch:

• 11da15d: 8269957: facilitate alternate impls of NameTable and Name
• 725ec0c: 8315020: The macro definition for LoongArch64 zero build is not accurate.
• 1c3177e: 8315029: [BACKOUT] Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index))
• dd23f7d: 8315039: Parallel: Remove unimplemented PSYoungGen::oop_iterate
• 5c4f1dc: 8314513: [IR Framework] Some internal IR Framework tests are failing after JDK-8310308 on PPC and Cascade Lake
• cf2d33c: 8299658: C1 compilation crashes in LinearScan::resolve_exception_edge
• 1664e79: 8311792: java/net/httpclient/ResponsePublisher.java fails intermittently with AssertionError: Found some outstanding operations
• 0901d75: 8314762: Make {@Incubating} conventional
• 12de9b0: 8314148: Fix variable scope in SunMSCAPI
• 7fbad4c: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes()
• ... and 57 more: https://git.openjdk.org/jdk/compare/3e1b1bf94e7acf9717b837085e61fc05a7765de4...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[AlanBateman]

@AlanBateman Is there anything else you need me to do? If so, please let me know. Thanks!

I don't think the JDK is the right place to workaround this issue. Also, we really need to get back re-implementing FileInputStream and friends on the new API, in which case the original issue will come back again. So I think it would be better to see how this can be fixed in the native image code.

[jerboaa]

@AlanBateman Is there anything else you need me to do? If so, please let me know. Thanks!

I don't think the JDK is the right place to workaround this issue. Also, we really need to get back re-implementing FileInputStream and friends on the new API, in which case the original issue will come back again. So I think it would be better to see how this can be fixed in the native image code.

OK. I understand. Withdrawing this PR then.