FTR: JVM Lang Summit presentation

[Remi Forax]

On 08/05/2014 09:55 AM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/pres/201407-JVMEvolution.pdf
>
> This includes a big segment on value types.
>
> Key slide:
>
> What is a value, for computers?
>
> * Any indication of quantity or quality, something like a symbol.
>    – Chosen from a fixed set of alternatives (dynamic range, alphabet).
>
> * Values can be recorded and copied at negligible cost. – Like written letters. Unlike clay tokens or coins.
>
> * All such values (symbols) can be resolved to bits. (Shannon, 1948) – They also occupy channels: Clay, paper, media, ether, cache lines.
>
> * In the setting of the JVM, a managed pointer, after “new”, is a value
>    – pre-existing managed pointer = special kind of bits.
>



slide 56:
   "can we somehow write that in the classfile ?"
   It seems to be the central question :)

   I see two different implementations, a one that use erasure and one 
that reify specialized type.
   1) erasure:
   if the specialized class only exists at runtime, there is no point to 
try to represent it in the bytecode, using it's erasure is enough. The 
erasure of Box<int> is Object (like the supertype of int[] and double[] 
is Object) and all methods that use Box<int> as receiver need to be 
erased to use invokedynamic (the reified type arguments is in that case 
passed as a bootstrap argument exactly like we do with lambdas)

   2) classdynamic.
   To implement classdynamic, we need a anchor point (the equivalent of 
the callsite of invokedynamic), the classdynamic anchor point is in my 
opinion a class name that is slightly different that the regular class 
name so when the VM will need it (more on that below) the VM will 
trigger the classdynamic bootstrap mechanism.
   In that case, Box<I>; can be a valid internal name with a special 
ClassDynamic class attribute that contains a table that associates an 
internal name to its bootstrap info.

   Unlike invokedynamic, the classdynamic bootstrap mechanism is a 
little more complex because I think there are two boostrap calls, one 
occurs when the VM rerifies the bytecode and the second occurs the VM 
maps the method declaration to the method definition (constant pool + 
bytecode, native, etc).
   If you want to do specialization, the first one correspond more or 
less to use the signature attribute instead of the descriptor, the 
second one to bytecode rewriting (at least if 'v' bytecodes can not be 
used on primitives).
   In case of a generic method invocation, you just have several calls 
of the second bootstrap mechanism with different specializations.

   BTW, I like the way the classdynamic mechanism is orthogonal to the 
classloader mechanism :)

slide 71:
   I still think VarHandle is not a good idea. Having two way to 
represent roughly same thing, MethodHandle and VarHandle, is not a good 
idea.

cheers,
Rémi

* what about the relation between an instance and its class, by example.