On Thu, 8 Sep 2022 21:41:09 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... @kevinjwalls - If you do a comment with "/issue JDK-8293564", then you'll include the other bug ID that has a test affected by the same underlying issue with this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10218
