RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3]
Kevin Walls
kevinw at openjdk.org
Fri Sep 16 17:00:35 UTC 2022
On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls <kevinw at 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.
OK, just updated to address the needless else.
It should be clear that this loop is only to give it a couple of tries to fetch the eden as a fraction, retrying if the heap is shrinking.
The previous allocations and System.gc calls being in the loop does not appear necessary.
This currently always causes an allocation as far as I can see in testing, including with the params that have caused failures.
This change does not address that the whole percentage of heap/memory is kind of strange and maybe unnecessary. If there are future problems, maybe we just allocate eden size in bytes instead, but for now I'd like to go ahead with the change here.
-------------
PR: https://git.openjdk.org/jdk/pull/10218
More information about the serviceability-dev
mailing list