RFR: Enforce GC workers constraint

Aleksey Shipilev shade at redhat.com
Thu Sep 6 20:19:28 UTC 2018


On 09/06/2018 10:03 PM, Zhengyu Gu wrote:
> On 09/06/2018 03:32 PM, Roman Kennke wrote:
>> Am 06.09.2018 um 21:25 schrieb Aleksey Shipilev:
>>> On 09/06/2018 08:53 PM, Zhengyu Gu wrote:
>>>> CMS and G1 enforce GC worker constraint:
>>>>    Parallel workers >= Concurrent workers
>>>>
>>>> Shenandoah should probably do so.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/gc_worker_constraints/webrev.00/
>>>
>>> The patch is okay, and probably sensible. But do we need to do this? Does it allow for any
>>> convenience in our code? I can mind-wrestle the example where having more concurrent threads (e.g.
>>> 4) than parallel (e.g. 2) is beneficial. Seems inconvenient to tie them together without the reason.
>>>
> Well, do we really have cases that want to have more concurrent threads than parallel? If not, this
> constraint does help eliminate some code to balance queues in parallel phases.

I can imagine such a case. It is based on idea that we'd need to cut down the number of parallel
threads to avoid scheduling overheads during pause where there is no need for too many threads. This
is different from having lots of concurrent threads that share the work during longer concurrent phases.

Let me think about this for a while. Meanwhile, maybe you can estimate how much Shenandoah code goes
away with this?

-Aleksey




More information about the shenandoah-dev mailing list