Idea how to implement VT/VO compatibility in JVM

Maurizio Cimadamore maurizio.cimadamore at
Thu Jan 22 13:42:16 UTC 2015

On 22/01/15 13:36, Stéphane Épardaud wrote:
> On 01/22/2015 02:21 PM, Maurizio Cimadamore wrote:
>> Object o = new ArrayList<Point>();
>> where Point is a value class.
>> Now,
>> o instanceof ArrayList<Point> //?
>> Or, as translated by our current prototype:
>> o instanceof ArrayList${0=QPoint;} //yes!
> And that's good!
>> But how about:
>> o instanceof ArrayList<?> //?
> Yes, because it would be also an `instanceof ArrayList<Object>` with 
> my proposal. I know at runtime we end up with two separate classes for 
> `ArrayList<Object>` and `ArrayList<Point>`, but if `ArrayList<Point>` 
> has all the bridge methods to satisfy `ArrayList<Object>` we can make 
> `instanceof ArrayList<?>` return true for any instance of `ArrayList` 
> regardless of value type arguments. So yeah, I agree it's not entirely 
> limited to compiler support and we need some support from the VM, but 
> that's already the case since we expect specialisation to be handled 
> by the VM to generate pseudo-classes.
That's mostly where I was trying to get at - bridges are a part of your 
approach - but it seems like some other part is missing in order to make 
the approach consistent.
> BTW, aren't you afraid of the proliferation of specialised classes at 
> runtime for the VM? I know PermGen moved away, but still, classes are 
> expensive to load…
As you might know, I did some work on reification in my early days [1] - 
among the things I found when implementing a JVM with support for 
reification was that in real-world cases, the number of different 
instantiation of the same generic class tends to be quite low. Of course 
this is another area where we need more evidence.

[1] -


More information about the valhalla-dev mailing list