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