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

[Markus Grönlund]

On Tue, 30 Jul 2024 08:17:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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.

Sampled oops are referenced by weak handles in the JFR sample priority queue. When the recording stops, an operation (EventEmitter) occurs that dumps the ObjectSamples in the priority queue and possibly, using an exclusive safe point operation, walks the paths-to-gc-roots. Can you explain more what you mean by "wait for old objects to appear"? Appear where?

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

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