Idea how to implement VT/VO compatibility in JVM

[Maurizio Cimadamore]

On 22/01/15 13:53, Vitaly Davidovich wrote:
>
> Maurizio,
>
> Have you seen this blog post before: 
> http://joeduffyblog.com/2011/10/23/on-generics-and-some-of-the-associated-overheads/
>
Haven't seen that post exactly - but was generally aware of the problems 
described there (thx for sharing!).

One key difference between the reification approach I implemented and 
the C# one was that I was mainly using an homogenoeus translation - i.e. 
only one class and a type token attached to the object header. Now, 
constructing type tokens is rather quick, i.e. no need to really load a 
class - so in my approach the proliferation of generic types was kind of 
less of an issue. I remember that when running javac codebase against 
the reified VM I was getting more or less 400 distinct type tokens, 
which is not a lot considering the size of the javac codebase. If those 
numbers are still true today, then I think we should be fine - note that 
javac codebase already an extreme case of a biggie codebase that is 
heavily generified. Another interesting experiment which didn't exist 
back then would be the Stream API, which is also heavily generified (and 
performance critical).

Maurizio
>
> This is from .NET perspective but I imagine java would be similar.
>
> sent from my phone
>
> On Jan 22, 2015 8:42 AM, "Maurizio Cimadamore" 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>
>     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] -
>     https://apice.unibo.it/xwiki/bin/view/Theses/MaurizioCimadamorePhd
>
>     Maurizio
>