On constant folding of final field loads

[Andrew Haley]

On 07/21/2015 05:29 PM, Vladimir Ivanov wrote:
>>>>> Andrew, can you comment on why you decided to stick with absolute
>>>>> offsets and not preserving Unsafe.getInt() addressing scheme?
>>
>>> (The outcome is that the unaligned guys have the same signatures as
>>> the aligned ones.)
>>
>> Indeed it does.
>>
>> I had a look around at the way Unsafe.getXXX(Object, long) is used.
>> One of the most common usages is with arrays.  There, the offset is
>> the result of address arithmetic so it cannot be an opaque cookie, and
>> there is no way to make it so without breaking all usages with arrays.
> Yes, it can't be a completely opaque cookie, but it doesn't mean it 
> should be a raw offset.
> 
> Array addressing mode is the following:
>     BASE + index * SCALE
> 
> where both BASE & SCALE are produced by Unsafe.
> 
> Such addressing scheme permits encodings which are linear in byte offset.

Mmm, okay.  I see what you mean: clever tricks are possible with some
encodings.  Even tag bits.  However, I can guarantee you that there is
code in the JDK which knows that ARRAY_BYTE_INDEX_SCALE == 1.  And lots
of other places too, I'm sure.

>> Also there is the guarantee that you can use
>> Unsafe.getXXXUnaligned(null, address) to fetch data from an absolute
>> address in memory.  To discover that this latter usage is explicitly
>> allowed surprised me, but it does mean that the offset can not be an
>> opaque handle unless we special-case the null form.  And I think we
>> don't want to do that.
>
> That's a valid argument. 1-1 correspondence between Unsafe methods & 
> machine ops is appealing.
> 
> I'm curious do you use any additional addressing modes for unaligned 
> variants? getXXX(Object, long) supports: (1) NULL + address, (2) obj + 
> offset, and (3) base + index * scale (for arrays). Anything besides that 
> for unaligned?

I don't think that getXXXUnaligned places any restrictions on its callers
at all.  There aren't any other forms used in the JDK.

Andrew.