RFR(XS): JDK-8212122: Allow ReferenceProcessor to always be MT processing

Roman Kennke rkennke at redhat.com
Fri Oct 12 14:56:21 UTC 2018

Currently, in ReferenceProcessor, the mt_processing flag is adjusted for
each phase depending on the number of workers: if it's 1 worker, then
mt_processing is disabled, for more than 1 worker, mt_processing is
enabled. Depending on the flag, ref-processing is either done through
AbstractRefProcTaskExecutor, or directly in VMThread. However, we have a
situation where we always want to execute via the executor, and never
directly. Instead we decide in the executor whether or not we want to
execute directly in the VMThread.

A simple change allows a subclass of ReferenceProcessor to change this

In case you're interested why we need to do this: Shenandoah requires
(for each worker) a scope around reference processing. In current
scheme, we'd need to put one scope around
RP::process_discovered_reference() to cover the 1-threaded case, and one
scope inside each worker to cover those. However, we cannot handle this
sort of weirdly nested scoping.

(If it was me, I'd rework this whole execution scheme to always call the
MT config, and let RP figure out and execute directly in VMThread if
it's only 1 worker, and not put this burden on the caller to set up both
for 1-threaded and N-threaded execution. This is just an ugly mess.)


Testing: passes hotspot/tier1 locally. Works well with Shenandoah too.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20181012/1692e50f/signature.asc>

More information about the hotspot-gc-dev mailing list