ValueConversion.unbox* fixes(?)

[Christian Thalinger]

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