RFR 8204947: Port ShenandoahTaskTerminator to mainline and make it default

Zhengyu Gu zgu at redhat.com
Thu Nov 29 15:04:40 UTC 2018


Hi Roman,

The RFE has following sentence:

"Port it to mainline and make it default; optionally allow switching to 
the old one for one release."

It strikes to me that there is an option to switch back to old 
terminator through VM option. Thomas, could you clarify?

Thanks,

-Zhengyu

On 11/29/18 9:45 AM, Roman Kennke wrote:
> Ok.
> 
> I'm really not sure we actually want an extra flag for this. Maybe just
> hardcode G1 and Parallel to use the new terminator, and CMS to keep
> using the old one? Or would that only make things more complicated?
> 
> Roman
> 
>> Updated version also passed submit tests.
>>
>> -Zhengyu
>>
>> On 11/28/18 10:26 PM, Zhengyu Gu wrote:
>>> Webrev updated to suppress multiple copy constructors and assignment
>>> operators warnings on Window.
>>>
>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8204947/webrev.01/
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>> On 11/28/18 2:08 PM, Zhengyu Gu wrote:
>>>> Hi,
>>>>
>>>> ShenandoahTaskTerminator is based on Google's work stealing protocol,
>>>> described in paper [1]. The implementation diverges in a way to
>>>> emphasize termination latency vs. power efficiency (see comments in
>>>> code for details).
>>>>
>>>> Shenandoah switched to ShenandoahTaskTerminator as default
>>>> terminator, shortly after it was implemented, and has been very
>>>> stable since.
>>>>
>>>> On performance side, it showed better termination latency on almost
>>>> all tests/benchmarks I ran, comparing to ParallelTaskTerminator. As
>>>> the result, we (Shenandoah) purged fallback branches and uses it as
>>>> the sole task terminator.
>>>>
>>>> This patch introduces a new experimental flag "UseOWSTTaskTerminator"
>>>> (default: true), and switches G1 and Parallel GC to use it as default
>>>> terminator. You can switch back to ParallelTaskTerminator with JVM
>>>> option "-XX:+UnlockExperimentalVMOptions -XX:-UseOWSTTaskTerminator"
>>>>
>>>> I did not port it to CMS, as it is depreciated.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204947
>>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8204947/webrev.00/
>>>>
>>>> Test:
>>>>     hotspot_gc and vmTestbase_vm_gc on Linux 64.
>>>>
>>>>
>>>> [1] Understanding and improving JVM GC work stealing at the data
>>>> center scale (http://dl.acm.org/citation.cfm?id=2926706)
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
> 



More information about the hotspot-gc-dev mailing list