On Fri, 9 Sep 2022 09:28:38 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.) > > Kevin Walls has updated the pull request incrementally with one additional > commit since the last revision: > > Clarify that loop is for checking heap not changing. Exception if > continually changing. This code still isn't sitting right with me and I'm still not sure of it's original intent. The method is called `provokeGc`, but it seems to be quite a bit more complex than that. It (used to) loop 3 times, each time calculating the youngGen size as a % of the heap size (according to the MemoryPoolMXBean values). It then (on each iteration) allocates that much memory by applying the % to Runtime.maxMemory(), and does so twice. It could have just allocated the youngGen size twice, but instead used the round about way of determining how much to allocate. I'm not sure why. In any case, the end result should be triggering at least one youngGen GC per iteration, but more likely two unless it was empty at the start. Then it follows this up with a full GC (on each iteration). So what is the point of any of this? It it testing consistency of the MemoryPoolMXBean values? Is it testing the relation between the MemoryPoolMXBean heap size and Runtime.maxMemory()? You have changed it to only do the allocation part once rather than on every iteration, so now the loop is only checking if the heap is still shrinking, but just because heapSize == heapSize0 doesn't mean it's not shrinking. It can just mean no GC happened between the two Pools.getHeapCommittedSize() calls. I think maybe the original intend was to do the allocateHeap() part while the heap is shrinking, not just once after it has stabilized. BTW, make sure you test with ZGC. ------------- PR: https://git.openjdk.org/jdk/pull/10218
