Casting reference array to any-T array.

[Michael Barker]

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