Doubling down on the erasure vs constant pool specialization

[Remi Forax]

Hi all,

There is a nice talk about implementing generics with separate compilation in Swift:
https://youtu.be/ctS8FzqcRug

I really think we should follow a similar road, their "witness table" is very similar to what the specialization part of a species can be, obviously all the data structure used for representing generics should be created by the VM not by the compiler.
They are only able to specialize the code if the source is available, but we have the VM JITs for that.

During the question at the end, there is an interesting remarks that separate compilation of value types and generics specialization are parts of the same mechanism. 

Rémi

----- Mail original -----
> De: "Remi Forax" <forax at univ-mlv.fr>
> À: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 6 Décembre 2017 15:47:41
> Objet: Doubling down on the erasure vs constant pool specialization

> Hi John, hi all,
> i've read the doc you send us during our last meeting on the classfile
> specialization,
> while it's powerful i do not think we need to do constant pool specialization at
> least to implements generics over primitives and value types.
> 
> One of the results of the MVT prototype is that we need Q types only for the
> layout, you do not need Q types to represent value types on the stack, so we
> should not need to specialize the signature of a method if the class is
> generified, we can use Object as carrier type, an Object can represent
> reference type by subtyping and primitive and value type by buffering. If we do
> not need method descriptor specialization, we do not need vtable
> specialization, etc.
> 
> We have 3 places where we can specialize the Java code, at bytecode level, at
> constant pool level, at JIT level, i believe we should investigate trying to do
> the specialization at JIT level only, mostly because it doesn't have the
> complexity of doing the specialization at constant pool level and it is the
> same level of bet as saying that we can use Object as a carrier type for all Q
> types.
> 
> So here is my counter proposal: doubling down on the erasure, let method
> descriptor to use Object, introduce class species and method species, make the
> few bytecodes that deals with the layout species aware.
> 
> for a field, like for Q-type field, the field need to be annotated with the type
> variable of the species, so when the layout is created, the VM can decide or
> not to specialize the layout
> for array, again, array are species so the component type is reified (again, the
> VM can decide to not specialize the array) and tested when storing an element.
> 
> in term of bytecode, we have two kind of bytecodes that need to have there
> semantics changed,
> - new/anewarray, and all invoke* need to be able to send (out of band) argument
> types to create a species-class or a species-method,
>  this can be done by using a typevar bytecode as prefix, the typevar being able
>  to specify either a type argument, or a type variable from the current
>  species-class or species-method
> - getfield/aaload doesn't need to be changed, they will both put an Object on
> stack
> - for putfield, a supplementary check to type argument of the species is needed
> before storing the value.
> - for aastore, the component check already exist.
> 
> regards,
> Rémi