RFC: 8204690: Simplify usage of Access API

[Roman Kennke]

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:
>>
>> Hi Kim,
>> I need to digest all this.
> 
> I understand; there’s a fair amount of detail here.
> 
>> 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 assume you meant s/OOP_IS_NULL/OOP_NOT_NULL/, which we’re
> proposing to rename IS_NOT_NULL.

Oops, yes.

> 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.

Thanks,
Roman