P4
There are places where oops are compared, using pointer comparison, which is problematic for Shenandoah. operator== and operator!= will be addressed as part of Shenandoah. The other operators are very nearly unused, and it would be better to eliminate them than to fix them.
We can tell whether we've eliminated them, because oop is defined as a class when CHECK_UNHANDLED_OOPS is true. (Otherwise, oop is a typedef for oopDesc*.) If the oop class doesn't provide these operators and there are still uses of them, then we'll get compiler errors when CHECK_UNHANDLED_OOPS is true (which it is for fastdebug builds).
oop::operator{<,>,<=,>=} currently has a total of 3 uses, of which 2 are in code specific to some other GC. There is only one shared use, and it would be better to have an oop_compare(oop, oop) operation that can be specialized appropriately.
oop::operator! permits one to write code such as "if (!obj) ...". That's contrary to the Hotspot Style Guide, which discourages implicit booleans. This is also very nearly unused (currently a handful of uses), and should be removed.
We can tell whether we've eliminated them, because oop is defined as a class when CHECK_UNHANDLED_OOPS is true. (Otherwise, oop is a typedef for oopDesc*.) If the oop class doesn't provide these operators and there are still uses of them, then we'll get compiler errors when CHECK_UNHANDLED_OOPS is true (which it is for fastdebug builds).
oop::operator{<,>,<=,>=} currently has a total of 3 uses, of which 2 are in code specific to some other GC. There is only one shared use, and it would be better to have an oop_compare(oop, oop) operation that can be specialized appropriately.
oop::operator! permits one to write code such as "if (!obj) ...". That's contrary to the Hotspot Style Guide, which discourages implicit booleans. This is also very nearly unused (currently a handful of uses), and should be removed.