RFC: (How to?) Replace use of mark-word in leak-profiler (Lilliput)
Markus Gronlund
markus.gronlund at oracle.com
Tue Oct 12 12:37:28 UTC 2021
Hi Roman,
Thank you for bringing this up.
I am exploring a few ideas, and I will get back to you soon.
Cheers
Markus
-----Original Message-----
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.java.net> On Behalf Of Roman Kennke
Sent: den 8 oktober 2021 17:44
To: hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>; lilliput-dev at openjdk.java.net
Subject: RFC: (How to?) Replace use of mark-word in leak-profiler (Lilliput)
Hi there,
I'm currently thinking about an issue that came up when I tested JFR/Leakprofiler with Lilliput.
First come context: In Lilliput I am storing a (compressed) Klass* in the object header, and want to phase out all uses of the dedicated Klass*-word and then remove that. This means that we need to be a little more careful when accessing the object header and/or the object's klass.
In the leak-profiler, we (temporarily) store an Edge* into the object header, and preserve the actual mark in a table. However, that means that the heap traversal would not work anymore because the object doesn't have a valid Klass* anymore.
Therefore I'm thinking about alternative ways to associate objects with an Edge*:
1. Use a (hash-)table for it (oop->Edge*), in EdgeStore.
2. Compress the Edge* to 32bits and store that only in the lower 32bits of the header (the Klass* is in the upper 32bits, currently). Not quite sure how to do this, though, it means we have to control allocation of the Edge instances in a contiguous space.
3. Store the object Klass* somewhere as long as we have it (before overriding it in EdgeStore::associate_leak_content_with_candidate()),
and use that for iterating the object (in BFSClosure::iterate()). But where? Maybe in the Edge to the object? I.o.w. each Edge would also store the Klass* of its pointee?
I wanted to check with you if any of those approaches make sense to you, or maybe you have even better ideas?
Thanks for helping,
Roman
More information about the hotspot-jfr-dev
mailing list