Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8135660 | emb-9 | Kim Barrett | P4 | Resolved | Fixed | team |
The class VerifyNoCSetOopsClosure directly derives from both OopClosure and ObjectClosure, each of which derive (non-virtually) from Closure. Hence, the verify class contains two distinct Closure bases.
That multiple inheritance was in support of different iteration functions that needed different closure types. However, the recent removal of SATB buffer checking (JDK-8073717) has eliminated the need for ObjectClosure support.
So we can remove ObjectClosure from the base classes of the VerifyXXX class. Though it might be worth looking at the places where it is used, to see if we can instead use ObjectClosure in preference to OopClosure. OopClosure requires overloading do_oop on both oop* and narrowOop*, but the VerifyXXX class is only applied to oop* ranges and so defines the narrowOop* as ShouldNotReachHere().
That multiple inheritance was in support of different iteration functions that needed different closure types. However, the recent removal of SATB buffer checking (JDK-8073717) has eliminated the need for ObjectClosure support.
So we can remove ObjectClosure from the base classes of the VerifyXXX class. Though it might be worth looking at the places where it is used, to see if we can instead use ObjectClosure in preference to OopClosure. OopClosure requires overloading do_oop on both oop* and narrowOop*, but the VerifyXXX class is only applied to oop* ranges and so defines the narrowOop* as ShouldNotReachHere().
- backported by
-
JDK-8135660 VerifyNoCSetOopsClosure is derived twice from Closure
-
- Resolved
-