Simplifying reified generics with partial specialization
brian.goetz at oracle.com
Mon Jan 5 17:30:44 UTC 2015
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  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.
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).
More information about the valhalla-dev