Using Array.newInstance still generates checkcast instructions

Vitaly Davidovich vitalyd at gmail.com
Wed Oct 28 19:54:15 UTC 2015


>
> Try re-doing your experiment by
> reifying the T[] type, not the T (element) type.  Make sure your use of
> Array.newInstance takes its metadata from a call to getComponentType.


I'm not sure I understand you correctly John.  Why is the issue related to
Array.newInstance? It does produce the expected reified array, String[] in
this case, and to me it looks like the T[] is reified.  My question is more
about uses of that field not looking at the runtime type of the array to
see if checkcast can be trivially removed.  Did I misunderstand? If I did
misunderstand, what should my example ArrayList look like?

On Wed, Oct 28, 2015 at 3:40 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Oct 27, 2015, at 11:14 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> Here's the basic example I used earlier, a bit more spelled out + assembly:
>
>
> (This is going back several years.)  Look at the code in
> Arrays.copyOfRange.
> Note how the call to Array.newInstance is passed newType.getComponentType.
> That part is important.  The C2 intrinsic only optimizes the case where
> the ARRAY
> Class is available, not the ELEMENT Class.  Try re-doing your experiment by
> reifying the T[] type, not the T (element) type.  Make sure your use of
> Array.newInstance takes its metadata from a call to getComponentType.
>
> Perhaps this could be upgraded; maybe it is time to.  The old code shape
> is designed for the case where constant folding is infrequent, and the
> dynamic (non-constant) version works best when you start with the T[] type.
>
> — John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151028/40e48ae8/attachment.html>


More information about the hotspot-compiler-dev mailing list