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

Roman Kennke rkennke at openjdk.org
Tue Jul 30 08:52:31 UTC 2024


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

> > > Leak Profiler is notorious in using the mark words for its own needs.
> > 
> > 
> > It seems to already use external storage for some of the leak profiling work. Can it be taught -- at least when Shenandoah is being used -- to just use external storage for its book-keeping/tagging as well to avoid this interference?
> 
> Yes, but as I mentioned in PR body, this is a continuous whack-a-mole game. At this point, I believe bailing from unsafe modes is a saner tactics.

The 'unsafe' part is that JFR meddles with the mark-word, and it can be argued that it shouldn't be any of JFR's business to do so. Avoiding to touch the mark-word altogether would be the sanest tactic, IMO. JFR could use a bitmap for 'marking' objects, pretty much like is done in JVMTI for very similar purpose. (See https://github.com/openjdk/jdk/blob/156f0b4332bf076165898417cf6678d2fc32df5c/src/hotspot/share/prims/jvmtiTagMap.cpp#L1487) The ObjectBitSet that is used there is well-suited for that purpose because it only allocates chunks as needed, and thus avoids allocating a full bitmap that covers all of the heap.

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

PR Comment: https://git.openjdk.org/jdk/pull/20328#issuecomment-2257818242


More information about the hotspot-jfr-dev mailing list