RFR: Use heuristics to determine the number of conc threads for each conc gc cycle

[Zhengyu Gu]

I am not sure either, I withdraw it for now and try to find some "real" applications.
I think benchmarks distort the heuristics.

I will separate clean up and send RFR for that part only.

Thanks,

-Zhengyu


On 12/16/2016 10:10 AM, Roman Kennke wrote:
> Am Donnerstag, den 15.12.2016, 12:43 -0500 schrieb Zhengyu Gu:
>> This is an experimental heuristics that determines the number of
>> concurrent threads for each concurrent GC cycle.
>>
>> SPECjbb runs do not show obvious improvement, it seems to ramp up
>> load quickly, so conc thread count stays high.
>>
>>
>> The change set also contains some cleanup.
>>
>>
>> http://cr.openjdk.java.net/~zgu/shenandoah/conc-worker-heuristics/web
>> rev.00/
>>
>>
>> Test:
>>     SPECjbb, some of SPECjvm benchmarks.
>>
>>
>> Thanks,
>>
>> -Zhengyu
>>
> Interesting. I think the patch is ok.
>
> However, under which situation do you expect an improvement? Can we
> construct a benchmark for this?
>
> I think that applications with high alloc pressure (like SPECjbb) will
> push us to maximum threads. Low alloc pressure would let us stay lower
> too, but those apps would likely not be dominated by GC work anyway.
>
> Roman