RFR: 8358580: Rethink how classes are kept alive in training data

Coleen Phillimore coleenp at openjdk.org
Thu Jul 10 16:50:45 UTC 2025


On Thu, 10 Jul 2025 14:42:47 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> What a confusing comment, but luckily it points to Klass::keep_alive() for context.  Yes, please don't allocate an OopStorage handle directly.  Then the OopHandle constructor will check for native oom.
>> 
>> Otherwise this seems okay and better than using jni.
>
> @coleenp I kind of like the fact that I can get rid of a field in KTD that previously stored a handle. Perhaps that benefit justifies a direct allocation?
> 
> @shipilev I don't understand your comment about loading the mirror. I'm not merely loading it, I'm registering it as a root. It is also all happening in a safepoint-free context.

Then just have OopHandle handle = OopHandle(Universe::vm_global(), klass->klass_holder());

or similar.  You don't have to store it unless you're going to release it.  But footprint seems unimportant in this case.  Also, maybe OopStorage::allocate() should just be friends with OopHandle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26233#discussion_r2198233387


More information about the hotspot-dev mailing list