RFR (S): 8136854: G1 ConcurrentG1RefineThread::stop delays JVM shutdown for >150ms

[Tom Benson]

I agree, looks good.
Tom

On 2/3/2016 9:27 AM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2016-01-27 at 16:25 +0100, Thomas Schatzl wrote:
>> Hi,
>>
>> On Wed, 2016-01-27 at 09:37 -0500, Tom Benson wrote:
>>> Hi,
>>> Was the change tried on a small system to see if startup is
>>> actually
>>> slowed down there, by the much tighter loop consuming CPU?  I guess
>>> one possible answer is "we don't care that much about systems that
>>> small for G1. "
>> I did not try that, mainly because any delay using sleep() will very
>> likely be enough to move the thread off a cpu.
>>
>> The actual code that is tested inside the polling loop is extremely
>> little, so even with an extremely slow cpu (say, around 1Ghz) the
>> delay should be much larger than the cpu time spent on checking the
>> two conditions.
>>
>>> But Derek suggested an increasing delay scheme in the CR,
>>> which I don't think would be much more difficult than the current
>>> change, and could address that.
>> I will do some tests to see if different delays make a significant
>> difference in CPU usage on some "slow" machine for a "Hello World"
>> style program.
> So I did some tests with a nop-program, in general both user and real
> time go down significantly even with 1ms delay, sys time up slightly
> compared to 200ms.
>
> The only exception has been a raspberry pi (model b or b+, i.e. single
> core, 700 mhz) where due to increased sys time real time went up by
> around 10% (like 1.5s vs. 1.4s startup time, just did a few comparison
> runs).
>
> I also tried beefier, somewhat more recent ARM processors, and there I
> observed the expected improvements.
>
> Now one could try to improve the perf there too, but I do not think a
> rasppi is anything close to a platform we really support g1 on. Also
> the default collector for those is still serial GC. Imo time is spent
> better elsewhere.
>
> Thanks,
>    Thomas
>