RFR: 8338526: Don't store abstract and interface Klasses in class metaspace

Coleen Phillimore coleenp at openjdk.org
Thu Aug 22 12:30:06 UTC 2024


On Thu, 22 Aug 2024 09:12:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> I am surprised that this patch is so small. I would have assumed a lot of code exists that unconditionally assumes we always can encode decode Klass*<->narrowKlass.
> 
> I looked through the typical cases (eg Klass validation) and all of them seem to be okay. I will keep looking.

Thanks for looking at this @tstuefe. I was pleased that the change was small but once we identify the classes as AbstractClass instead of Class in metaspace, it just falls out. I thought CDS would have more changes, but CDS is all in one space and doesn't differentiate.  It's good that the only time we compress and uncompress klass pointers is when we get them out of an object and this should keep it that way.

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2304546143


More information about the core-libs-dev mailing list