Simplifying reified generics with partial specialization

[Ron Pressler]

Exactly. The storage will still be specialized, but the API will be boxed
(hence, partial specialization) and the boxing elided where possible. I'm
writing a response on how to deal with high-order functions which might
help the JVM with the possibly difficult (is it?) task of eliding boxing in
a deep "boxed API" stack.

Ron Pressler
paralleluniverse.co
@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 [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
>>
>>