Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8352942: jdk/jfr/startupargs/TestMemoryOptions.java fails with 32-bit build #641

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tkiriyama
Copy link

@tkiriyama tkiriyama commented Mar 26, 2025

Hi All,
I would like to add this bug fix for the bug in jdk/jfr/startupargs/TestMemoryOptions.java. This test contains 24 test cases and fails the "ThreadBufferSizeExceedMemorySize" case.
The cause of this bug is the memory allocation issue, which occurs only on 32-bit Server VM, not on Client VM or 64-bit JDK. The failure happens because Server VM's default heap size reduces available memory space, causing JFR to fail memory allocation.
To resolve this issue, -Xmx256M is explicitly set, matching the Client VM default heap size, ensuring sufficient memory space remains available for JFR.
I believe that this test verifies that the combination of memory options for JFR is valid or invalid and that the MaxHeapSize setting does not affect the verification.
Change has been verified locally, test-fix only, no risk.

Would someone please review this fix?


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
  • JDK-8352942 needs maintainer approval

Issue

  • JDK-8352942: jdk/jfr/startupargs/TestMemoryOptions.java fails with 32-bit build (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/641/head:pull/641
$ git checkout pull/641

Update a local copy of the PR:
$ git checkout pull/641
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/641/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 641

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/641.diff

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Mar 26, 2025

👋 Welcome back tkiriyama! 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
Copy link

openjdk bot commented Mar 26, 2025

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk openjdk bot added the rfr Pull request is ready for review label Mar 26, 2025
@mlbridge
Copy link

mlbridge bot commented Mar 26, 2025

Webrevs

Copy link
Member

@phohensee phohensee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check later JDKs (11, 17, 21, 24, tip). If it happens in all of them, please fix it in tip and then backport to earlier releases. You can use the existing JBS issue, just change version info.

@tkiriyama
Copy link
Author

@phohensee
Thank you for your comment.
I see. I'll check it. Sorry, let me confirm that first. Is 32-bit support being maintained in the later JDK versions (11, 17, 21, 24, tip)? If it is, I'm happy to fix this in the later JDKs.
It seems like there's already a lack of enthusiasm for 32-bit development in JDK 21.
https://openjdk.org/jeps/449

@phohensee
Copy link
Member

Yes, there is lack of enthusiasm for 32-bit ports, and the x86 32-bit port is in the process of being removed in JDK 25. But, the arm-32 port still exists in tip, and the LTS 32-bit ports are still supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rfr Pull request is ready for review
Development

Successfully merging this pull request may close these issues.

2 participants