Simplifying reified generics with partial specialization
ron at paralleluniverse.co
Mon Jan 5 18:11:18 UTC 2015
Sorry, I missed a part of your post:
> and calls for some upgraded VM treatment of fields to support some notion
of "field overriding"
Any hidden elements -- fields and local variables -- would simply be
specialized, just as in your proposal. In short: hidden behavior is
specialized, public API is boxed (and hopefully optimized).
@puniverseco <https://twitter.com/puniverseco> on Twitter
On Mon, Jan 5, 2015 at 7:30 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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.
>  http://mail.openjdk.java.net/pipermail/valhalla-dev/2014-
> 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
>> 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
>> 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
>> (Brian implied that classdynamic is intended to be trigger custom
>> generation anyway).
More information about the valhalla-dev