Arrays.copyOf does not work with value type arrays

Tobias Hartmann tobias.hartmann at oracle.com
Thu Mar 16 09:58:55 UTC 2017


Thanks John and Mr. Simms for the detailed answer!

I'll leave this for now.

Best regards,
Tobias

On 15.03.2017 18:48, John Rose wrote:
> On Mar 15, 2017, at 7:51 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>>
>> Hi,
>>
>> I'm looking into C2 intrinsic support for value types and noticed that below code fails with:
>>
>> Exception in thread "main" java.lang.BootstrapMethodError: call site initialization exception
>> 	at java.lang.invoke.CallSite.makeSite(CallSite.java:347)
>> 	at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:247)
>> 	at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:237)
>> 	at Test.main(Test.java:23)
>> Caused by: java.lang.ClassNotFoundException: java/util/Arrays$copyOf$433071630$${QPoint;}
>> 	at java.lang.Class.forName0(Native Method)
>> 	at java.lang.Class.forName(Class.java:372)
>> 	at java.lang.invoke.GenericStaticDispatch.metafactory(GenericStaticDispatch.java:14)
>> 	at java.lang.invoke.CallSite.makeSite(CallSite.java:308)
>> 	... 3 more
>>
>> Is this supposed to work with MVT1.0?
> 
> This is not supposed to work in MVT1.0 because __ByValue and __Make keywords
> introduce source-level types not present in MVT1.0.  The type "array-of-Q-Point" is
> going to be confusing to existing library code, until it is properly generified.
> 
> (The type "array-of-L-Point" would not be problematic, but it is undesirable since
> each Point is boxed as an L-Point.  Such are the tradeoffs of MVT1.0.)
> 
> MVT1.0 allows the user to work with "flat" arrays of values ("array-of-Q-Foo")
> but *only* through method handles, not directly in source code.
> 
> To get the source code story straightened out, we need to formulate the rules
> for distinguishing "array-of-Q-Foo" from "array-of-L-Foo".  The latter type, is
> relatively useless and perhaps can be omitted totally, but I think that legacy
> code might have an occasional need to work with it.  In any case it's an open
> issue, and MVT1.0 avoids it.
> 
> — John
> 


More information about the valhalla-dev mailing list