RFR (S): 8198561: Make oop and narrowOop always have their own class type (original) (raw)
Kim Barrett kim.barrett at oracle.com
Wed Mar 14 21:41:09 UTC 2018
- Previous message: RFR (S): 8198561: Make oop and narrowOop always have their own class type
- Next message: RFR (S): 8198561: Make oop and narrowOop always have their own class type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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::isnull(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
- Previous message: RFR (S): 8198561: Make oop and narrowOop always have their own class type
- Next message: RFR (S): 8198561: Make oop and narrowOop always have their own class type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]