-
Notifications
You must be signed in to change notification settings - Fork 6.3k
8366980: TestTransparentHugePagesHeap.java fails when run with -UseCompressedOops #27143
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
Conversation
👋 Welcome back stefank! A progress list of the required criteria for merging this PR into |
@stefank 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:
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 37 new commits pushed to the
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 |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm.
Thanks for the reviews! |
Going to push as commit 703d930.
Your commit was automatically rebased without conflicts. |
The new test TestTransparentHugePagesHeap.java added in JDK-8366434 fails when run with -UseCompressedOops.
The reason for this is that the address printed as the start of the heap in the pagesize logging is not the start of the mapping. So we fail to find the mapping when scanning the SMAPS file.
There reason why this happens is that Linux has merged the memory area for the heap with some other memory. Sometimes it is the marking bitmaps and sometimes it's just malloc that mapped some memory.
I propose that we change the test to find the smaps memory area that contains the start address of the heap and verify that that area is THP eligible.
I'm using BigInteger to represent the parsed addresses to skip having to deal with negative values in longs.
Tested locally with the reproducer. I'm also testing with tier1 and the tier that found this issue.
The fix is localized in TestTransparentHugePagesHeap.java so that it can easily be incorporated into a backport of JDK-8366434.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27143/head:pull/27143
$ git checkout pull/27143
Update a local copy of the PR:
$ git checkout pull/27143
$ git pull https://git.openjdk.org/jdk.git pull/27143/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 27143
View PR using the GUI difftool:
$ git pr show -t 27143
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27143.diff
Using Webrev
Link to Webrev Comment