RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants

John Rose john.r.rose at oracle.com
Tue May 3 21:01:45 UTC 2016

On May 3, 2016, at 11:43 AM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
>> library_call.cpp:
>> *) What is the point for doing this check:
>> 2372   if (_gvn.type(base)->isa_ptr() != TypePtr::NULL_PTR) {
>> 2373     heap_base_oop = base;
>> 2374   }
>> In old code heap_base_oop != top() only for heap ptrs, even if base is
>> NULL. In new code, if base is NULL, then heap_base_oop is top(). It
>> would seem that new code is better, because it clearly separates heap
>> vs. native accesses, and it does not seem to break anything downstream.
>> Was that the intent?
> Those three lines were actually donated to my by John Rose, so I'm hoping he or somebody else more knowledgeable in C2 can provide some helpful comments on the correctness and validity of that specific change.

Yes, the intent is that heap_base_oop is top (= absent) if the base argument is constant null (from any source).

The heap_base_oop is present (i.e., it's not top) if and only if the base argument might be non-null.

If it might be non-null, then some logic needs adjusting.  The GC might need a handshake, and we might try to constant-fold from a Java object field.

In the worst case, base may be either null or non-null, and we get here:

        // We can't tell at compile time if we are storing in the Java heap or outside
        // of it. So we need to emit code to conditionally do the proper type of
        // store.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160503/f15a3578/attachment-0001.html>

More information about the hotspot-compiler-dev mailing list