Casting reference array to any-T array.
mikeb01 at gmail.com
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