Removing G1 Reference Post Write Barrier StoreLoad Barrier
thomas.schatzl at oracle.com
Mon Dec 22 17:52:25 UTC 2014
On Mon, 2014-12-22 at 09:09 -0800, Jon Masamitsu wrote:
> One concern regarding the use of asymmetric Dekker synchronization
> (ADS) is how well this technique scales to 1000's of threads. Do you
> have an
> implementation where you can measure the scalability?
another potential problem is that mutator threads might (and already
do in some workloads) also help with refinement.
At the moment they do rather do too little. They will most likely need
to contribute more of the refinement workload in the future (if only
1000s of mutator threads drown out the refinement threads due to
scheduling). This is known problem.
In this case amortization over a large number of cards or buffers might
not work out (as in: preventing timely processing to avoid too long gc
Nothing too hard I would believe, off the top of my head you could store
the core id in the buffer you just completed, and then force a
rendezvous with that other core. This is maybe useful in any case.
(Haven't thought it through).
Other than that, yes, we are definitely interested in improvements in
that area. :)
More information about the hotspot-gc-dev