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

[Aleksey Shipilev]

On Tue, 30 Jul 2024 10:11:37 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

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

All right, I think I misunderstood how sampling works. I assumed it happens from the GC cycle, but now I see it happens from the allocation path. Indeed sampler holds the object in weak oop storage, and they are supposed to be accessible immediately after the allocation. 

I tightened up comments to reflect this understanding. Looks better, or?

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

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