8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes #1492
Conversation
…cided on incompatible initial and minimum heap sizes
|
/issue add JDK-8257230 |
|
👋 Welcome back jiefu! A progress list of the required criteria for merging this PR into |
|
@DamonFool This issue is referenced in the PR title - it will now be updated. |
|
@DamonFool |
|
@DamonFool The |
Webrevs
|
|
This is really something the GC folk should review. /label add hotspot-gc |
|
@dholmes-ora |
| @@ -1906,7 +1906,7 @@ void Arguments::set_heap_size() { | |||
|
|
|||
| reasonable_initial = limit_by_allocatable_memory(reasonable_initial); | |||
|
|
|||
| FLAG_SET_ERGO(InitialHeapSize, (size_t)reasonable_initial); | |||
| FLAG_SET_ERGO(InitialHeapSize, MAX2((size_t)reasonable_initial, MinHeapSize)); | |||
There was a problem hiding this comment.
I'm not sure this is a good fix, this would violate the limit set by:
limit_by_allocatable_memory(reasonable_initial);
Wouldn't the proper fix be to make sure that MinHeapSize is also limited by what's allowed to allocate?
There was a problem hiding this comment.
The change just follows what is done for MaxHeapSize.
MaxHeapSize is limited by reasonable_max = limit_by_allocatable_memory(reasonable_max) [1].
But it will be set to MAX2(reasonable_max, (julong)MinHeapSize) [2] if MinHeapSize is set.
What do you think?
[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1876
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1885
There was a problem hiding this comment.
I agree that the fix is in line with the current code and I guess setting MinHeapSize should override MaxVirtMemFraction and allow us to use more than half the address space specified.
In this case I think I would prefer moving the the call limit_by_allocatable_memory(reasonable_initial); [1] to right after the calculation on line 1902 [2]. This way we would only have one line doing lower limiting and one line doing upper limiting.
Makes sense? Or will that lead to some other problem?
[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1902
There was a problem hiding this comment.
In this case I think I would prefer moving the the call
limit_by_allocatable_memory(reasonable_initial);[1] to right after the calculation on line 1902 [2]. This way we would only have one line doing lower limiting and one line doing upper limiting.
Good suggestion!
Will test it soon.
Thanks.
The jtreg test had been added. |
|
/test |
|
@DamonFool you need to get approval to run the tests in tier1 for commits up until 0389bc4 |
|
/test |
|
@DamonFool you need to get approval to run the tests in tier1 for commits up until 92208d4 |
| * @comment Not run on AIX as it does not support ulimit -v | ||
| * @requires os.family != "aix" |
There was a problem hiding this comment.
I would change this to only be run on Linux:
* @requires os.family == "linux"
| public static void main(String[] args) throws Throwable { | ||
| String cmd = ProcessTools.getCommandLine(ProcessTools.createTestJvm( | ||
| "-XX:MinHeapSize=" + "260m", "-version")); | ||
| cmd = escapeCmd(cmd); |
There was a problem hiding this comment.
If we change to only run on Linux, this is not needed.
| String cmd = ProcessTools.getCommandLine(ProcessTools.createTestJvm( | ||
| "-XX:MinHeapSize=" + "260m", "-version")); |
There was a problem hiding this comment.
createTestJvm() will pick up additional options passed by the test runner and there might be conflicting options. So I would suggest not picking up any additional options.
| oa.shouldNotContain("hs_err") | ||
| .shouldNotContain("Internal Error"); |
There was a problem hiding this comment.
Should it also check that the exit status is ok, or can't we expect that for sure?
|
Hi @kstefanj , Thanks for your review. The fix has been updated according to your comments. I don't check the exit value because I found different platforms may return different values (Zero on MacOS, but non-zero on Linux). Thanks. |
|
It should be 0 on Linux and after the addition of |
Hi @kstefanj , The test is used to check whether the assert is triggered. As I mentioned above, there seems to be another bug on Linux. What do you think? Thanks. |
|
Yes it might check that the assert doesn't trigger, but if the test is not robust enough to always manage to execute |
Hi @kstefanj , After some experiments, I finally got a configuration which can return 0 on Linux. |
|
@DamonFool 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 33 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 |
|
Hi @tschatzl , Are you OK with the latest change? |
|
Didn't see any problems with the test in the testing environment, so I'm good. |
openjdk
bot
added
integrated
|
@DamonFool Since your change was applied there have been 33 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 7620124. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
|
Mailing list message from David Holmes on hotspot-runtime-dev: On 7/12/2020 7:30 pm, Jie Fu wrote:
We are seeing the new test crash on Aarch64 due to native OOM. https://bugs.openjdk.java.net/browse/JDK-8257820 Cheers, |
Is it always reproducible? |
|
I had hoped my testing would have caught this, but might be that the test is to brittle after all. I saw it pass on aarch64, so not happening every time. I would be good with removing the test as a fix. |
|
Mailing list message from David Holmes on hotspot-runtime-dev: On 7/12/2020 10:15 pm, Jie Fu wrote:
No. It passed when this commit was integrated, but then failed in later David |
OK. |
It has been assigned to @tschatzl . |
Hi all,
Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator.
For example, this assert [1] fired on our testing boxes.
It can be reproduced by the following two steps on Linux-64:
The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize.
One more important fact is that this bug can be more common on Linux-32 systems.
Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M.
Testing:
Thanks.
Best regards,
Jie
[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907
[3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/1492/head:pull/1492$ git checkout pull/1492