On constant folding of final field loads
vladimir.x.ivanov at oracle.com
Tue Jul 21 16:29:08 UTC 2015
>>>> 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.
> 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(Ojbect, long) supports: (1) NULL + address, (2) obj +
offset, and (3) base + index * scale (for arrays). Anything besides that
More information about the hotspot-compiler-dev