FTR: JVM Lang Summit presentation
forax at univ-mlv.fr
Tue Aug 5 15:35:54 UTC 2014
On 08/05/2014 09:55 AM, John Rose wrote:
> 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.
"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.
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)
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 :)
I still think VarHandle is not a good idea. Having two way to
represent roughly same thing, MethodHandle and VarHandle, is not a good
* what about the relation between an instance and its class, by example.
More information about the valhalla-dev