RFR (S): 8136854: G1 ConcurrentG1RefineThread::stop delays JVM shutdown for >150ms
thomas.schatzl at oracle.com
Wed Feb 3 14:27:18 UTC 2016
On Wed, 2016-01-27 at 16:25 +0100, Thomas Schatzl wrote:
> 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
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
More information about the hotspot-gc-dev