Simplifying reified generics with partial specialization

[Brian Goetz]

A reasonable idea (and, probably not surprising, we've investigated big 
parts of this too).  Some people have speculated "why can't values just 
be 'fast objects'", to which the answer is that they can be for purposes 
of passing data between methods, but cannot for purposes of storing data 
in the heap.

Your proposal, if I read it correctly, splits these issues, using 
elidable boxing where we can (a la Albert Noll's work on heisenboxing, 
which allows us to put boxed types in APIs and optimize away the boxing 
cost for the data-passing part of the problem (but not the heap-storage 
part of the problem, see [1] and related thread) to handle the data 
movement part, and calls for some upgraded VM treatment of fields to 
support some notion of "field overriding" (no small request, but not as 
insane as some other suggestions we've received.)

Note that the first part is really just an implementation choice; what 
it does is reduces the invasiveness of specialization, by limiting how 
much code has to be specialized, pushing the work to the VM to optimize 
away box/unbox conversions; it's mostly just turning one of the knobs.

[1] 
http://mail.openjdk.java.net/pipermail/valhalla-dev/2014-November/000380.html

On 1/5/2015 7:10 AM, Ron Pressler wrote:
> Hi. I've been following the discussion here, and I think there's a simple
> solution that will satisfy everyone: let us enjoy the performance gains of
> specialization, maintain full backwards compatibility, keep the generic
> class hierarchy simple and intuitive, and remove the need for layers. The
> cost would be relying on JVM optimizations for full performance (which is,
> I think, what Java has always done).
>
> The idea is simple: a generic instantiation over a value type would
> specialize fields (and array fields, obviously) and local variables, but
> not arguments and return values of non-private methods. These would use the
> value type's (or primitive's) boxed counterpart and will be erased (or not
> -- depending on how reference erasure will be done under Valhalla).
>
> This would mean that ArrayList<int> will implement List<Integer> (and will
> therefore extend List and List<?>) and Object will essentially be the Any
> type (and List<int>, if allowed, would just be an alias for List<Integer>).
> It would also mean that we automatically get the performance benefits
> associated with the flattened arrays used to store the ArrayList's data.
> However, for full performance, it would rely on JVM employing escape
> analysis (or even a simpler optimization) to elide boxing.
>
> More advanced forms of specialization (such as those made possible by
> layers) would be possible, but not by using direct Java syntax, but by
> employing a library like ASM, but this is a topic for a separate discussion
> (Brian implied that classdynamic is intended to be trigger custom
> generation anyway).
>
> Ron
>