RFR (S): 8198561: Make oop and narrowOop always have their own class type

Kim Barrett kim.barrett at oracle.com
Wed Mar 14 21:41:09 UTC 2018


> On Mar 14, 2018, at 9:19 AM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Alright, thank you for the explanations.
> 
> The main reason why I wanted this change was so that we could overload
> == (i.e. equality comparison of oops), and redirect it through
> BarrierSet or Access API.
> 
> Since this is not possible on pointers, e.g. oopDesc*, which is what oop
> is typedef'd to in release builds, the next reasonable option is to
> provide an explicit static method in oopDesc, e.g. oopDesc::equals(oop,
> oop) (and narrowOop version) which would then call into BarrierSet or
> Access APIs.
> 
> This would not be unprecedented: we already have oopDesc::is_null(oop)
> and oopDesc::compare(oop, oop).
> 
> In Shenandoah land, we already know all the places where to put
> oopDesc::equals() instead of ==, and we do have some code in
> oopsHierarchy to overload == in fastdebug builds and verify to not call
> naked == on oops.
> 
> Would that be a reasonable way forward? If yes, then I can provide an
> RFR soon.
> 
> WDYT?

This is the direction Coleen and I were thinking things would go when we
removed operator! and the non-equality comparison operators from the 
class implementation of oop:

https://bugs.openjdk.java.net/browse/JDK-8196199
Remove miscellaneous oop comparison operators



More information about the hotspot-dev mailing list