On 03/09/2015 04:59 PM, Paul Sandoz wrote:
>
> On Mar 9, 2015, at 5:04 PM, Andrew Haley <a...@redhat.com> wrote:
>
>> On 03/09/2015 03:10 PM, Paul Sandoz wrote:
>>> Do you want to tackle the single-address access methods as a follow up
>>> issue?
>>
>> It's not clear to me that we need any single-address access methods
>> because we can pass in a null object. Personally I would prefer that.
>> Thoughts?
>>
>
> I agree that would be desirable.
>
> I know that people rely on that behaviour for off-heap CAS etc, but
> i was wondering about such behaviour given that the base and offset
> should, as documented, be derived from an object/staticFieldBase and
> objectFieldOffset/staticFieldOffset respectfully.
The doc for Unsafe.getInt() says:
public int getInt(java.lang.Object o,
long offset)
Fetches a value from a given Java variable. More specifically, fetches
a field or array element within the given object o at the given
offset, or (if o is null) from the memory address whose numerical
value is the given offset.
Therefore it seems to me that passing in a null object to the
unaligned methods would be entirely legitimate and in keeping with the
rest of Unsafe.
> Are there subtle differences? I looked at the C2 code and it seems
> the results might be equivalent but i cannot say the same for C1
> from quickly eyeballing the code.
>
> e.g. LibraryCallKit::inline_unsafe_access:
>
> if (!is_native_ptr) {
> // The base is either a Java object or a value produced by
> Unsafe.staticFieldBase
> Node* base = argument(1); // type: oop
> // The offset is a value produced by Unsafe.staticFieldOffset or
> Unsafe.objectFieldOffset
> offset = argument(2); // type: long
> // We currently rely on the cookies produced by Unsafe.xxxFieldOffset
> // to be plain byte offsets, which are also the same as those accepted
> // by oopDesc::field_base.
> assert(Unsafe_field_offset_to_byte_offset(11) == 11,
> "fieldOffset must be byte-scaled"); <----- weird assertion
Indeed it is. There was in the past some weirdness to do with offset
being a kind of opaque handle rather than guaranteed to be a byte
offset; I guess that's what this assert is thinking of.
Andrew.
