Casting reference array to any-T array.

[Vitaly Davidovich]

Sorry, that's my fault - misspoke.  However,  main point still stands in
that optimizer isn't involved in this.  Now, if you're saying you guys are
considering moving this further into the VM then ok, I'll wait and see what
you have in mind.  Not immediately clear to me how you'd use profiling info
to selectively specialize and then reload types or some other heuristic,
but that's an interesting topic.

I guess one thing that's still unclear to me and makes having some of these
conversations a bit more difficult is exactly how much of this will be
pushed into the JVM (and how deep in there).  I'm sure you guys don't quite
know yet, but I guess we'll discover through these threads :).

Sent from my phone
On Jan 7, 2015 9:12 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> What makes you say that?  Right now, specialization is class-load time.
> With some possible changes to the VM (to be revealed when more baked) we
> can push it later and get more sharing.
>
> On 1/7/2015 7:35 PM, Vitaly Davidovich wrote:
>
>> Problem is specialization is javac-time, VM not involved.
>>
>> Sent from my phone
>>
>> On Jan 7, 2015 7:33 PM, "Michael Barker" <mikeb01 at gmail.com
>> <mailto:mikeb01 at gmail.com>> wrote:
>>
>>     Yes, but with a slight step further.  As you point out specialising
>>     everything will lead to bloating the number of classes.  I was
>>     thinking about Hotspot specialising some combinations of generic
>>     classes and specific reference types based on some
>>     heuristic/profiling information.
>>
>>     On 8 January 2015 at 11:32, Vitaly Davidovich <vitalyd at gmail.com
>>     <mailto:vitalyd at gmail.com>> wrote:
>>
>>         Ah, you're talking about specialized classes as a whole (I was
>>         referring to just the arrays aspect).  Yes, if it were to
>>         specialize every single type, then you'd get better type
>>         information.  Downside is you now explode the number of method
>>         definitions in the runtime.  In .NET, for example, generic
>>         methods are not specialized for reference types, in part for
>>         this reason I believe.  Generally speaking, the downside to
>>         creating distinct structures per type is the explosion in the
>>         number of types at runtime.  I encourage you to read this oldish
>>         blog post by Joe Duffy (MSFT engineer):
>>         http://joeduffyblog.com/2011/10/23/on-generics-and-some-of-
>> the-associated-overheads/
>>
>>         On Wed, Jan 7, 2015 at 5:23 PM, Michael Barker
>>         <mikeb01 at gmail.com <mailto:mikeb01 at gmail.com>> wrote:
>>
>>             My understand is that it does type profiling at the callsite
>>             and something like HashMap.hash() will encounter such wide
>>             variety of classes that it will rarely be anything other
>>             than fully mega-morphic.  My guess was that if there was
>>             specialised class for a specific reference type then this
>>             could become mono-morphic.
>>
>>             On 8 January 2015 at 11:12, Vitaly Davidovich
>>             <vitalyd at gmail.com <mailto:vitalyd at gmail.com>> wrote:
>>
>>                 Right, but the reason I'm doubtful that this will have
>>                 any impact is because the JIT already does type
>>                 profiling, and the runtime types it sees (and the
>>                 statistics around that) won't change due to erasure.  My
>>                 "make its life easier" comment was a guess that perhaps
>>                 some code paths in the optimizer don't need to be taken
>>                 (e.g. don't look at profiling info if it now knows
>>                 statically that an array is composed of final classes).
>>
>>                 On Wed, Jan 7, 2015 at 5:09 PM, Michael Barker
>>                 <mikeb01 at gmail.com <mailto:mikeb01 at gmail.com>> wrote:
>>
>>                             The current functionality continues with the
>>                             erasure plan.  However, I wouldn't mind
>>                             doing better!
>>
>>
>>                         Yeah, I can't immediately think of a critical
>>                         reason why it can't stay erased.  For JIT
>>                         optimizer, having a narrower upper bound on the
>>                         type may make its life easier, although I don't
>>                         know if it'll have any material difference.  The
>>                         one question is what reflection will do (and any
>>                         code based on reflection, such as custom
>>                         serialization, code generation, etc):
>>
>>
>>                     (Caveat, I'm not a compiler expert so this is a bit
>>                     of a guess.)
>>
>>                     One possible place where this could be used with
>>                     within the optimiser.  E.g. if Hotspot could see a
>>                     specialised HashMap<String, String> instead of an
>>                     erased one, then it could determine that calls to
>>                     hashCode and equals would be mono-morphic and apply
>>                     more aggressive in-lining.  This could lead to jump
>>                     in performance across a broad ranges of apps (hands
>>                     up who uses Strings and HashMaps :-).  My understand
>>                     is that the mega-morhpic dispatch (of
>>                     hashCode/equals) is one of the more significant
>>                     costs within HashMap.
>>
>>                     If that was possible then it would be pretty cool!
>>
>>                     Mike.
>>
>>
>>
>>
>>
>>