The GCLocker strikes again (bad remark / GCLocker interaction)

[Tony Printezis]

Hi there,

In addition to the GCLocker issue I've already mentioned (JDK-8048556: 
unnecessary young GCs due to the GCLocker) we're also hitting a second 
one, which in some ways is more severe in some cases.

We use quite large edens and we run with -XX:+CMSScavengeBeforeRemark to 
empty the eden before each remark to keep remark times reasonable. It 
turns out that when the remark pause is scheduled it doesn't try to 
synchronize with the GCLocker at all. The result is that, quite often, 
the scavenge before remark aborts because the GCLocker is active. This 
leads to substantially longer remarks.

A side-effect of this is that the remark pause with the aborted scavenge 
is immediately followed by a GCLocker-initiated GC (with the eden being 
half empty). The aborted scavenge checks whether the GCLocker is active 
with check_active_before_gc() which tells the GCLocker to do a young GC 
if it's active. And the young GC is done without waiting for the eden to 
fill up.

The issue is very easy to reproduce with a test similar to what I posted 
on JDK-8048556 (force concurrent cycles by adding a thread that calls 
System.gc() every say 10 secs and set -XX:+ExplicitGCInvokesConcurrent). 
I can reproduce this with the current hotspot-gc repo.

We were wondering whether this is a known issue and whether someone is 
working on it. FWIW, the fix could be a bit tricky.

Thanks,

Tony

-- 
Tony Printezis | JVM/GC Engineer / VM Team | Twitter

@TonyPrintezis
tprintezis at twitter.com