InstanceKlass today serves triple duty:
- It records the contents of a loaded classfile plus resolution states.
- It represents a "live type" (a subtype of
Klass) in the JVM bookkeeping.
- It is the pointer in the header of an instance of a heap-allocated object.
All of these duties add to the complexity of
InstanceKlass. Let's split
it up into two or three modules:
ClassFileStructuure, etc.) should be a loaded classfile, with an associated
ConstantPoolholding constants and their resolution states. Much of today's current contents of
InstanceKlassshould be renamed into this new class.
InstanceKlassshould become an abstract API with one implementation called
ClassFileKlass, which contains a pointer to a
ClassFile. These types should be "hollowed out", and only retain methods which seem directly applicable to a JVM bookkeeping over types. That includes methods shared with
The object header can contain a direct
InstanceKlasspointer, just as today. It can be encoded or decoded in the case of compression (or other tricks in the future).
When we start implementing specialization, a distinction will arise between three things:
- A plain class.
- A parametric class (what we used to call a "template class")
- A species of a parametric class.
Clearly cases 1 and 2 have a direct one-to-one relation to a
ClassFile structure, and case 3 does not. Instead, case 3 is in a
many-to-one relation to case 2. This suggests the following types:
InstanceKlassis abstract (we wanted to do this in the first place)
InstanceKlass(today's code, renamed)
- parametric paraphernalia added to
ClassInfoand parameter binding stuff
The parameter binding stuff needs to include constant pool states for
parametric constants: These are in a many-to-one relation to the
ConstantPool. We'll need a type for that,
to work underneath the proposed
Method knows where it belongs to because it has a
pointer to a constant pool, which then is in one-to-one relation to
ClassFile info around the method--all very cozy. For
specialized methods, this design can remain, since the parameter
binding for a specialized method call is associated with a stack
frame, rather than a method itself.
See also: http://mail.openjdk.java.net/pipermail/valhalla-dev/2020-October/008083.html