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