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