RFC: 8204690: Simplify usage of Access API

[Kim Barrett]

> On Jun 11, 2018, at 4:46 PM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Am 11.06.2018 um 22:35 schrieb Kim Barrett:
>>> On Jun 11, 2018, at 4:10 PM, Roman Kennke <rkennke at redhat.com> wrote:
>>> But may I throw in another ambiguity:
>>> 
>>> OOP_IS_NULL is, as far as I can tell, used to decorate an access where
>>> the *value* is known to be not null (for stores), or the value coming
>>> out of a load is known to be not null (for loads). This is useful for
>>> stuff like compressed oops, where a null-check can be elided if we know
>>> it's not null. However, at least when using this in Shenandoah land, it
>>> is also useful to know whether or not a target oop (the object being
>>> written to, or loaded from) is known to be not null, at least in
>>> compiled code. If it's known to be not null, we can elide a null-check
>>> on the read/write barrier around the memor access. I propose to
>>> disambiguate this by splitting the semantics into VALUE_NOT_NULL (or
>>> similar) and TARGET_NOT_NULL (or similar). Suggestions welcome!
>> I think what you are describing should be IS_NULL, which would be a pure
>> addition from where we are.
> 
> No. What I meant is the distinction between the value (of a load or
> sore) that is known to be not null and the target oop (to which we
> store, from which we load) known to be not null.
> 
> An IS_NULL property might be useful too, but as you say, I am not sure
> how much use it actually is.

Okay, I did misunderstand your suggestion.

If I understand correctly, you want to be able to say obj != NULL in
the following (via the Access decorators):

  Access<...>::oop_load_at(obj, offset)

But when would that be useful?  It seems to me that's an invariant
that must be guaranteed by the caller, and that oop_load_at can just
always make that assumption.  Indeed, I have no idea what oop_load_at
should do otherwise (other than segfault).