RFC: 8204690: Simplify usage of Access API
rkennke at redhat.com
Mon Jun 11 20:46:50 UTC 2018
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.
> 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.
More information about the hotspot-dev