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

[Markus Grönlund]

On Tue, 30 Jul 2024 10:42:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

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

I don't know. The backoff mechanism now introduced is to handle the special case where the LeakProfiler dump operation, even though it is performed under an exclusive safepoint, happens to to coincide with some phase of Shenandoah GC - a lot of surface for handling this special case.

Also, need this not be categorical for all OldObject tests?

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

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