factoring InstanceKlass for species, template, classfile, _klass, etc.
john.r.rose at oracle.com
Wed Oct 14 18:02:13 UTC 2020
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.
More information about the valhalla-dev