On Jan 12, 2011, at 12:17 PM, Rémi Forax wrote:
> On 01/12/2011 10:40 AM, Christian Thalinger wrote:
>> On Jan 11, 2011, at 10:13 PM, John Rose wrote:
>>> On Jan 11, 2011, at 7:30 AM, Christian Thalinger wrote:
>>>> On Nov 12, 2010, at 2:42 PM, Christian Thalinger wrote:
>>>>> On Nov 12, 2010, at 2:35 PM, Rémi Forax wrote:
>>>>>> Le 12/11/2010 12:26, Christian Thalinger a écrit :
>>>>>>> As I have already said, I'm not expert here but these changes let all
>>>>>>> tests of this testcase pass:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~twisti/6998541/webrev.00/test/compiler/6998541/Test6998541.java.html
>>>>>>>
>>>>>>> I'm not sure if the assumption is correct that every non-zero
>>>>>>> primitive value is a boolean true.
>>> Values of subword types (short, char, byte, boolean) are assumed to be
>>> confined to their ranges. For boolean, that range is [0,1]. The verifier
>>> does not enforce this, however.
>>>
>>>>>>> John, Remi, I'd like your opinion on that.
>>>>>>>
>>>>>>> -- Christian
>>>>>> Christian,
>>>>>> methods unboxRaw call unbox versions, so you have also changed
>>>>>> the semantics of all methods unboxRaw which seems a bad idea.
>>>>>
>>>>> Yeah, I'm also a bit worried about that. I think I leave that up to
>>>>> John to fix it properly.
>>> The "raw" retype transforms are not directly accessible to users. They are
>>> used by trusted code, which promises that any value will continue to be
>>> valid in its new type, after the raw retype.
>>>
>>> In the case of booleans, this means that a raw retype operation from int to
>>> boolean will always operate on a normalized value that was either (int)1 or
>>> (int)0.
>>>
>>>> John, is that actually a bug? -- Christian
>>> I don't see a bug here.
>> Should it be possible to change the return type from e.g. int to short with
>> something like:
>>
>> MethodHandle mh1 = MethodHandles.identity(int.class);
>> MethodHandle mh2 = MethodHandles.convertArguments(mh1,
>> MethodType.methodType(short.class, int.class));
>> short s = (short) mh2.invokeExact(123);
>>
>> Because what I get here is:
>>
>> Exception in thread "main" java.lang.ClassCastException: java.lang.Integer
>> cannot be cast to java.lang.Short
>> at sun.dyn.util.ValueConversions.unboxShort(ValueConversions.java:66)
>> at
>> sun.dyn.util.ValueConversions.unboxShortRaw(ValueConversions.java:102)
>> at sun.dyn.ToGeneric$Adapter.return_I(ToGeneric.java:393)
>> at sun.dyn.ToGeneric$A1.invoke_I(ToGeneric.java:643)
>> at Test.main(Test.java:7)
>
> The spec says that convertArguments only allow lossless primitive
> conversions i.e it allows
> widening primitive conversions but not narrowing primitive conversions.
> So the implementation is Ok here.
>
> If you want to convert an int to a short, you can use explicitCastArguments.
>
> MethodHandle mh1 = MethodHandles.identity(int.class);
> MethodHandle mh2 = MethodHandles.explicitCastArguments(mh1,
> MethodType.methodType(short.class, int.class));
> short s = (short) mh2.invokeExact(123);
Yeah, it was a bad example. But the same happens with widening:
Exception in thread "main" java.lang.ClassCastException: java.lang.Short cannot
be cast to java.lang.Integer
at sun.dyn.util.ValueConversions.unboxInteger(ValueConversions.java:56)
at sun.dyn.ToGeneric$Adapter.return_I(ToGeneric.java:393)
at sun.dyn.ToGeneric$A1.invoke_I(ToGeneric.java:643)
at Test.main(Test.java:7)
I'm just trying to mimic the same return type conversions I had with
InvokeDynamic.
-- Christian
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
