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

Coleen Phillimore coleenp at openjdk.org
Fri Aug 23 19:29:06 UTC 2024


On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore <coleenp 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.

Yes, is_in_klass_space was just to direct where to deallocate the metaspace pointer.  In your patch isn't the contains metaspace call still very slow?  Or I suppose for class space, it's not because it's a fixed space.  But it's not an inlined call at all because I had to search in cpp files for the range check.
+  const bool is_class = Metaspace::contains_in_class_space(ptr);

I sort of think it might be better for the outside runtime code to control this and the metaspace call assert if its wrong.

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

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


More information about the core-libs-dev mailing list