RFR [L][3/7]: 8197850: Calculate liveness in regions during marking (original) (raw)
Thomas Schatzl thomas.schatzl at oracle.com
Mon Mar 5 14:41:42 UTC 2018
- Previous message (by thread): RFR [S][2/7] 8197570: Make rules for choosing collection set candidates more explicit
- Next message (by thread): RFR [L][3/7]: 8197850: Calculate liveness in regions during marking
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi all,
can I have reviews for this change that calculates the liveness in regions (below nTAMS) during marking?
This is required to be more clever about selecting the regions G1 is going to rebuild the remembered sets for (i.e. the well-known G1MixedGCLiveThresholdPercent threshold).
This slows down the marking part of the concurrent phase a bit, but all alternatives were worse:
initially rebuild everything and then drop remembered sets for regions for too highly occupied regions at cleanup: wastes lots of space and memory maintaining these superfluous remembered sets.
choose regions using previous marking cycle data: this is generally not a good idea if your marking cycles are infrequent (which should be the normal case), as it tends to make too few regions available for evacuation (e.g. eager reclaim may already reclaim a lot). I.e. you need extra headroom, or be more aggressive with rebuilding.
The main change, next to the calls that add the liveness to some internal data structure every time an object is marked, is some per- thread cache that (G1RegionMarkStatsCache). It helps decreasing the synchronization overhead the (atomic) increments in the global result cause.
It is a very simple fixed size hashmap where increments to the same entries are collected, and on collision evicts the previous entry, doing the atomic operation on the global result.
There is also some unfortunate moving of code that is required to flush these caches correctly during mark overflow handling.
CR: https://bugs.openjdk.java.net/browse/JDK-8197850 Webrev: http://cr.openjdk.java.net/~tschatzl/8197850/webrev/index.html Testing: hs-tier 1-5; the next change will add an assert that verifies that this concurrently calculated value is correct at the end of rebuild, i.e. the results will always verified.
Thanks, Thomas
- Previous message (by thread): RFR [S][2/7] 8197570: Make rules for choosing collection set candidates more explicit
- Next message (by thread): RFR [L][3/7]: 8197850: Calculate liveness in regions during marking
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]