Casting reference array to any-T array.

Michael Barker mikeb01 at
Thu Jan 8 01:20:37 UTC 2015

Aaah, okay.  For some reason I'd convinced myself that VM would have the
mechanics to actually do the specialisation.

On 8 January 2015 at 13:35, Vitaly Davidovich <vitalyd at> 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> 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> 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):
>>> On Wed, Jan 7, 2015 at 5:23 PM, Michael Barker <mikeb01 at>
>>> 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>
>>>> 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>
>>>>> 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.

More information about the valhalla-dev mailing list