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

[Thomas Schatzl]

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