Casting reference array to any-T array.

[Michael Barker]

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> 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> 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> 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>
>>> 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.
>>>>
>>>
>>>
>>
>