RFR: 8338929: Make Metaspace::deallocate space-aware
Thomas Stuefe
stuefe at openjdk.org
Mon Aug 26 12:57:04 UTC 2024
On Mon, 26 Aug 2024 12:23:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> For ucoming Lilliput changes, as well as to simplify [JDK-8338526](https://bugs.openjdk.org/browse/JDK-8338526), we should make Metaspace::deallocate space-aware (as in, instead of having to tell it where the pointed-to block resides, it should know it on its own).
>>
>> As of now, callers need to tell the function of the deallocated block is in class space or in non-class metaspace. That is unnecessary and won't work for TinyCP. The deallocation function can do this better on itself by doing a range check on the class space range.
>
> src/hotspot/share/memory/metaspace.hpp line 123:
>
>> 121: return is_in_shared_metaspace(ptr) || // in cds
>> 122: is_in_class_space(ptr) || // in class space
>> 123: is_in_nonclass_metaspace(ptr); // in one of the non-class regions?
>
> So the shared_metaspace region, which is the memory for CDS is *not* in class_space? I suppose for deallocate this doesn't matter since this memory is never deallocated.
By terminology, it is not in class space.
Class space I (we? don't we all?) call the section that is governed by the metaspace allocator. The CDS region containing Klass is not in class space. It is, however, in the *narrow Klass decoding range*:
- Klass decoding range: [CompressedKlassPointers::base() ... CompressedKlassPointers::base() + CompressedKlassPointers::range() )
- that range contains the CDS klass range, followed (after a possible gap) by the traditional class space. If CDS is off, its just the class space.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20701#discussion_r1731202187
More information about the hotspot-runtime-dev
mailing list