RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v4]

Aleksey Shipilev shade at openjdk.org
Tue Jul 30 08:22:35 UTC 2024


On Mon, 29 Jul 2024 19:48:25 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Roman's review: more precise GC state check, more includes
>
> test/jdk/jdk/jfr/event/oldobject/TestFieldInformation.java line 55:
> 
>> 53: 
>> 54:         // OldObjectSample is emitted at the end of the recording, and we need
>> 55:         // to let GC catch up before we do the event. There is no reason to wait
> 
> This notion of a "GC catching up" confuses these tests. Why should the GC " catch up" before a recording is stopped? If you need to use this construct here, please specify that it applies only to Shenandoah GC and not to GCs in general.

This applies to any concurrent GC, really.

We have allocated things, GC might have been triggered, we need to wait for "old objects" to appear now. Old object sampling is done at the end of the recording. Current tests assume that "old" objects appear "instantaneously" after the allocations -- which is somewhat sane for STW collectors, but not for the concurrent ones. The fact that Shenandoah does not report old objects while GC is running is just a facet of this general problem.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20328#discussion_r1696534654


More information about the hotspot-jfr-dev mailing list