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