On Thu, 8 Sep 2022 09:56:05 GMT, Kevin Walls <kev...@openjdk.org> wrote:
> Test update to cope with heap size changing (shrinking) in the early life of > the test app. > > A change in GC timing affects this test which reads eden size and heap size. > Both eden and heap are likely to shrink initially for this test. Failures > were that heap size shrank after reading eden size, such that eden appeared > to be >100% of heap. > Recognising a shrinking heap and retrying resolves this. > > (Re-ordering to read heap size then eden would be enough to make the check in > provokeGc work. But it would allocate sometimes a very small fraction of the > heap, which is not the intent.) Right, that outer loop is the original test, and it's not obvious if it is needed at all. Testing without it is fine, for all the tests in that directory. Possibly it was to make "really sure" we allocate enough memory to cause a GC. But after allocating whatever fraction of memory eden is, it does that again, and then calls System.gc(). No reason to do that 3 times... ------------- PR: https://git.openjdk.org/jdk/pull/10218
