RFC: 8204690: Simplify usage of Access API

Kim Barrett kim.barrett at oracle.com
Mon Jun 11 20:35:54 UTC 2018


> 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.  Both IS_NULL and IS_NOT_NULL are properties
of the value referred to by the access location.  I thought about mentioning the
possibility of IS_NULL in this RFE, but decided to limit to a transition from the
current state to the (we think) more desirable naming and semantics, and not
add new features as part of these changes.

That feature might benefit G1 as well as Shenandoah.  I’m not sure how much
benefit there is though.  It seems like it would mainly be useful for initialization
stores.  In the old pre-Access & associated compiler changes world, there was
a mechanism for the compiler to elide the SATB pre-barrier for initialization stores,
but I haven’t followed all the recent changes, so don’t know how that’s dealt with
now.

> I'll dig more into the proposal and probably come up with more comments.

Good.



More information about the hotspot-dev mailing list