factoring InstanceKlass for species, template, classfile, _klass, etc.

[John Rose]

This morning some of us had an excellent conversation about the role of `InstanceKlass` in the JVM after we start wiring up flattening and scalarization information.  Here are some thoughts about it.

1. `InstanceKlass` today serves triple duty:  (a) It records the contents of a loaded classfile plus resolution states, (b) it represents a “live type” (a sort of `Klass) in the JVM internals, and (c) it is the pointer in the header of an instance of an object (when it has a header!).

2. The name `InstanceKlass` is tilted towards 1(c), the “thing in the instance header”.

3. Specialized instances comprise a “binding”, a composition of (alpha) a loaded template class, and (beta) a collection of parametric arguments.

4. This suggests that `SpeciesKlass` and `TemplateKlass` are possible entities in the JVM (both <: `Klass`), and/or that 1(a) `ClassFileInfo` and 1(b) `SpeciesKlass` (<: `Klass`), and maybe even 1(c) `InstanceKlassInfo` are types we could introduce to represent new stuff and/or refactorings of old stuff.

5. Backing up, in reality today’s `InstanceKlass` has three aspects, which we should give provisional names for:  1(a) information on a loaded class file (cf. JVMS 4.1. The ClassFile Structure), 1(b) a live type (the C++ super `Klass`), and 1(c) the `_klass` field in the header.  I like to distinguish 1(c) because there are very special rules for working with the `_klass` field, which are distinct from its role in 1(b).  Also, I’d like to use the term “plain class” (or the more high-falutin’ “invariant class”) to mean “a regular old class which is free of any template stuff”.

6. FTR, I (currently) think that factoring out the classfile structure is the efficient move, so today’s `InstanceKlass` (N.B. whether it is renamed to `PlainKlass` or not!) points to a (unique) `ClassFileStructure`, while tomorrow’s `SpeciesKlass` points to a shared (by multiple species) `ClassFileStructure` which contains template stuff derived from its class file.

7. In the grand scheme of things, I don’t see a need or motivation to factor out a new type `TemplateClassFileStructure` from (the extended) `ClassFileStructure`, any more than we have a distinction between `InterfaceInstanceKlass` and `ClassInstanceKlass`.  It’s all one classfile format in the JVM, I assume, for now.  (If we decide to use a completely different file format for templates, then, yes, a new C++ data structure should reflect that decision.  But it seems very likely we’ll add templating on top of class file structure, not as a new file type.)

8. Thus:  `ClassFileStructure` would contain everything known/knowable when a `.class` file is loaded.  It’s constant pool “stuff” is associated with today’s resolution states.

9. And: we add an indirection to `InstanceKlass` to point to all the `ClassFileStructure` goodness.  Perhaps it goes via the constant pool (for purlely technical reasons, to cut out an indirection on some fast paths).  Perhaps (again for purely technical reasons) some of the `ClassFileStructure` is copied or hoisted into the `InstanceKlass`, for fast path access.

10. Then we add `SpeciesKlass` which points to whatever a parameter binding is (I call it `ParameterBinding` in my draft), *plus* a `ClassFileStructure`.

11. Probably `SpeciesKlass` is a subtype of `InstanceKlass`, not merely of `Klass`.  In that case maybe there’s another type `PlainKlass`, or (more likely) `InstanceKlass` has the obvious pointer to `ClassFileStructure` and `SpeciesKlass` *extends* that.

12. There’s potentially a temporary advantage to having `_klass` point to a restricted type, such as `ClassFileStructure`, and having a second word (optional, injected only in species instances) point to the parameter binding.  I’m on the fence about this, given all of the above.