RFR: 8129417: Oop iteration clean-up to remove oop_ms_follow_contents

Stefan Johansson stefan.johansson at oracle.com
Mon Jun 22 14:53:51 UTC 2015


Hi,

Please review these changes for RFE:
https://bugs.openjdk.java.net/browse/JDK-8129417

Webrev for the full change:
http://cr.openjdk.java.net/~sjohanss/8129417/hotspot.00/

Summary:
To allow further cleanups and later remove G1 specific code from 
mark-sweep, we want to remove the mark-sweep specific visitor 
oop_ms_follow_contents. Doing this cleanup has proven to be a little 
more complicated than I first anticipated and to make the change easier 
to review I've split it into four different parts.

Part 1 - removing oop_ms_follow_contents:
http://cr.openjdk.java.net/~sjohanss/8129417/1-remove-oop_ms_follow_contents/hotspot.00/

This is more or less what the RFE is all about, the other changes are 
needed to avoid introducing a regression. To be able to remove the 
mark-sweep specific visitor oop_ms_follow_contents the generic visitor 
oop_oop_iterate for all *Klass classes needs to be able to handle the 
mark-sweep case correctly. This is done by adding more functionality to 
the Devirtualizer and make use of it in the generic visitors.

The MarkAndPushClosure is also added to the set of closures that are 
specialized to avoid using virtual calls during the iteration.
---

Part 2 - introducing oop_iterate_size:
http://cr.openjdk.java.net/~sjohanss/8129417/2-add-oop_iterate_size/hotspot.00/

As stated above the cleanup to remove oop_ms_follow_content give a 
slight regression. One reason for this regression was the fact the 
oop_ms_follow_content didn't care about calculating the size for the 
object it iterated, but the generic visitors do. When looking through 
the code base it is clear that only a subset of the users of 
oop_iterate() really cares about the size and to solve this regression 
and make it possible to iterate without calculating the size I've added 
oop_iterate_size(). It is implemented using oop_iterate() (now void) but 
also calculates the size.
---

Part 3 - restructure mark-sweep:
http://cr.openjdk.java.net/~sjohanss/8129417/3-re-structure-mark-sweep/hotspot.00/

Both a cleanup and a way to avoid part of the regression on some 
platforms. We want to avoid having too much code in the inline.hpp 
files, but we also want all compilers to be able to inline call in a 
good manor. This part of the change moves a lot of code from 
markSweep.inline.hpp to markSweep.cpp and also try to structure it to 
allow good inlining.
---

Part 4 - compiler hints for inlining:
http://cr.openjdk.java.net/~sjohanss/8129417/4-compiler-hints-for-inlining/hotspot.00/

To avoid having regressions it seems to be very important that certain 
code-paths are correctly inline. To achieve this we need to hint the 
compiler in some parts of the code.

The change does two things:
* Avoid inlining the slow-path for Stack::push() when using gcc
* Add always_inline for Solaris in instanceKlass.inline.hpp (same as 
what is already present for Windows compiler)
---

Testing:
* Adhoc RBT run for functionality - no new failures.
* Adhoc aurora.se run for performance - no obvious regression.
* Many local runs tuned to do Full GCs a lot to verify that there is no 
obvious regression.

Thanks,
Stefan


More information about the hotspot-gc-dev mailing list