RFR: 8362657: Make tables used in AOT assembly phase GC-safe [v2]

Aleksey Shipilev shade at openjdk.org
Tue Jul 22 09:00:42 UTC 2025


On Tue, 22 Jul 2025 06:47:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/heapShared.hpp line 389:
>> 
>>> 387: 
>>> 388:   static CachedOopInfo* get_cached_oop_info(oop orig_obj) {
>>> 389:     OopHandle oh(&orig_obj);
>> 
>> `OopHandle`-s have no destructors, so this leaks?
>
> This only allocates a temporary `OopHandle` on the stack for the purpose of doing a look-up. The storage of this is allocated on the stack (the address of the local variable `obj`). So there's no leak here.
> 
> 
>   OopHandle oh(&obj);
>   return archived_object_cache()->get(oh) != nullptr;
> 
> 
> When an `OopHandle` is stored in the `archived_object_cache()`, we will allocate the storage from `Universe::vm_global()`. This  storage should be freed when the `archived_object_cache()` is deleted, but we currently never delete that table, as we assume the VM will soon exit after AOT assembly is done.

Oh, there is a special constructor, I missed that:
https://github.com/openjdk/jdk/blob/ed70910b0f3e1b19d915ec13ac3434407d01bc5d/src/hotspot/share/oops/oopHandle.hpp#L47C1-L47C42

I thought we go through a normal allocation path that leaks the slots in relevant `OopStorage`.

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

PR Review Comment: https://git.openjdk.org/leyden/pull/86#discussion_r2221799054


More information about the leyden-dev mailing list