Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC

[John Rose]

On Sep 28, 2010, at 2:04 PM, Tom Rodriguez wrote:

> That doesn't seem clearer to me.  If the shift should be 24 then why isn't that the value in vminfo in the first place?

The adapter data are validated and adjusted by init_AdapterMethodHandle in methodHandles.cpp.  I suppose the value could be set to 24 at that point, but it would have to be done by platform-specific code factored somehow into methodHandles_sparc.cpp.

That value happens to be the number of insignificant bits (or padding bits) in the value, when it is viewed as embedded in a 32-bit Java int (and/or JVM stack slot).  This is a platform-independent value.

It might be clearer if it were the number of significant bits: 1 for boolean, 8 for byte, 16 for char and short.  As it is, it is 31, 24, and 16 (respectively), which is more convenient for both Intel and SPARC.  The agreement about this value is between methodHandles.cpp and methodHandles_<cpu>.cpp.

> That whole section of code is mysterious in terms of what cases it's actually supposed to handle and how.  I've exchanged a bit of email with Christian about it and I think he's working on some tests to exercise these conversions more.  What are the possible input and output types?  Is it only the direct mappings between the boxed and unboxed forms, like Integer -> int, or can it do arbitrary conversions like Short -> byte?


That code handles two kinds of conversions: from subword (16 bits or less) to int, and from box to primitive (32 bits or less).

There is no short->byte, since an incoming short on the stack is always represented as an int slot.

-- John