The product option GCLockerInvokesConcurrent was introduced by JDK-6919638 as part of fixing a bad interaction between GCLocker GCs and +ExplicitGCInvokesConcurrent for CMS. (A GCLocker GC would wait for the concurrent collection to complete, which was not desirable.)
It was added to retain support for requesting that GCLocker GCs would (attempt to) trigger a concurrent collection cycle, but separate it from +ExplicitGCInvokesConcurrent. Even at the time it was noted that this might be a suboptimial policy.
This option was only used by G1 and CMS. CMS has been removed (JDK-8232365). G1 had a serious bug until very recently (JDK-8233279, 2019-11-13), and even with that fixed the feature remains suboptimal. Better to just remove it.
It was added to retain support for requesting that GCLocker GCs would (attempt to) trigger a concurrent collection cycle, but separate it from +ExplicitGCInvokesConcurrent. Even at the time it was noted that this might be a suboptimial policy.
This option was only used by G1 and CMS. CMS has been removed (
- csr for
-
JDK-8233877 Remove GCLockerInvokesConcurrent
-
- Closed
-
- relates to
-
JDK-8192647 GClocker induced GCs can starve threads requiring memory leading to OOME
-
- Open
-
-
JDK-8232365 Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
JDK-8229049 JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector
-
- Closed
-
(1 relates to)