ValueConversion.unbox* fixes(?)

[John Rose]

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.

But, I don't understand Remi's comment about changing the semantics of unboxRaw.  Can you explain a bit more?

Thanks,
-- John