Casting reference array to any-T array.

Michael Barker mikeb01 at
Wed Jan 7 22:09:39 UTC 2015

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


More information about the valhalla-dev mailing list