Casting reference array to any-T array.

Vitaly Davidovich vitalyd at gmail.com
Wed Jan 7 22:12:26 UTC 2015


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


More information about the valhalla-dev mailing list