[MVT] value type and getClass()

[forax at univ-mlv.fr]

I've spent the night of this, 
i think i do not need __Value anymore, 
the value can be boxed to Object, it will be a lightweight box that the JIT will escape, the trick is to make sure that all extractors will use the same value type. 

Rémi 

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Rémi Forax" <forax at univ-mlv.fr>
> Cc: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Envoyé: Samedi 5 Août 2017 21:28:03
> Objet: Re: [MVT] value type and getClass()

> On Aug 5, 2017, at 12:55 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
> wrote:

>> I want to use __Value as carrier type (between invokedynamic and the switch) in
>> a possible alternative translation of a pattern matching.

> Ultimately that is what we think we will use for C, as part of a general
> upward move from L-Object to U-Object. You are noticing that __Value
> is an early version of U-Object. It's not in the center of the MVT design,
> but it is something we are giving limited support for, so we can write
> our own polymorphic code (LFs).

> As a top-type for values, __Value can be dynamically checked and casted.
> (Or else the system is unsafe.) The details for how to do this are subject
> to change. In the end I expect to see bytecodes like instanceof and checkcast
> which operate on Q/U carriers, plus (when we get proper value classes)
> a method like or identical to getClass.

> — John