RFR: Partial GC

[Aleksey Shipilev]

On 03/13/2017 11:47 PM, Roman Kennke wrote:
> Am 13.03.2017 um 19:33 schrieb Aleksey Shipilev:
>> On 03/13/2017 07:30 PM, Roman Kennke wrote:
>>> Fixed everything except verification in full-gc. We can't really verify
>>> the matrix there because at no point during full-GC does the marking
>>> bitmap match the new addresses of objects, and therefore the new matrix.
>>> This is why I removed it.
>>>
>>> http://cr.openjdk.java.net/~rkennke/partialgc/webrev.02/
>> Ok then.
>>
>>> I found the the C2 matrix math optimization broke matrix updating. In
>>> order for partial gc to work correctly we either need to back that out
>>> or run without C2.
>> I would prefer to push this, and then figure out C2. Matrix stuff is under
>> construction anyway, and does not affect default operation.
>>
> Have committed+pushed it.
> 
> You'll noticed that -Xlog:gc+ergo shows zero regions in collection set
> and therefore root set. Without patch "Shenandoah matrix update barriers
> should be conditional." you should get a few regions. If you also print
> out num_incoming in ShenandoahPartialGC::prepare() you'll see that
> without the patch many regions get a fairly low number of regions
> (around 10) while with that patch, most are 100 or more, peaking out at
> many 100s.
> 
> Just to get us on the same page, I'm running like this:
> 
> ./build/linux-x86_64-normal-server-release/images/jdk/bin/java -Xlog:gc
> -Xlog:gc+ergo=debug -XX:ShenandoahGCHeuristics=partial -Xms8g -Xmx8g
> -XX:+UseShenandoahGC -XX:ArrayCopyLoadStoreMaxElem=0
> -XX:+UseShenandoahMatrix -XX:-UseCompressedOops -jar
> jmh-specjvm2016.jar  -f 0

I'll take a look at C2 code.

But what I notice when adding -XX:TieredStopAtLevel=1 there is that we SEGV in
the C1 generated code!

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fcae452465c, pid=4467, tid=4499
#
# JRE version: OpenJDK Runtime Environment (9.0) (build
9-internal+0-adhoc.shade.shenandoah-jdk9)
# Java VM: OpenJDK 64-Bit Server VM (9-internal+0-adhoc.shade.shenandoah-jdk9,
mixed mode, tiered, Shenandoah gc, linux-amd64)
# Problematic frame:
# J 1890 c1
com.sun.tools.javac.util.AbstractLog.getSource(Ljavax/tools/JavaFileObject;)Lcom/sun/tools/javac/util/DiagnosticSource;
jdk.compiler at 9-internal (50 bytes) @ 0x00007fcae452465c
[0x00007fcae45245e0+0x000000000000007c]

The same SEGV happens when I remove the conditionals from assembler/C1 stubs:

diff -r 48e1bf8fae32 src/cpu/x86/vm/macroAssembler_x86.cpp
--- a/src/cpu/x86/vm/macroAssembler_x86.cpp	Mon Mar 13 23:43:23 2017 +0100
+++ b/src/cpu/x86/vm/macroAssembler_x86.cpp	Tue Mar 14 00:58:45 2017 +0100
@@ -5381,10 +5381,7 @@
   addq(tmp, tmp2);
   // Address is _matrix[from * stride + to]
   movptr(rscratch1, (intptr_t) matrix_addr);
-  // Test if the element is already set.
-  testb(Address(rscratch1, tmp, Address::times_1), 0);
-  jcc(Assembler::notZero, done);
-  // Store true, if not yet set.
+  // Store true.
   movb(Address(rscratch1, tmp, Address::times_1), 1);
   bind(done);
 }
diff -r 48e1bf8fae32 src/share/vm/c1/c1_LIRGenerator.cpp
--- a/src/share/vm/c1/c1_LIRGenerator.cpp	Mon Mar 13 23:43:23 2017 +0100
+++ b/src/share/vm/c1/c1_LIRGenerator.cpp	Tue Mar 14 00:58:45 2017 +0100
@@ -1684,10 +1684,6 @@
   __ move(LIR_OprFact::intptrConst((intptr_t) matrix->matrix_addr()), tmp4);
   LIR_Address* matrix_elem_addr = new LIR_Address(tmp4, tmp1, T_BYTE);

-  LIR_Opr tmp5 = new_register(T_INT);
-  __ move(matrix_elem_addr, tmp5);
-  __ cmp(lir_cond_notEqual, tmp5, LIR_OprFact::intConst(0));
-  __ branch(lir_cond_notEqual, T_BYTE, L_done->label());
   __ move(LIR_OprFact::intConst((int) true), matrix_elem_addr);
   __ branch_destination(L_done->label());
 }

This kinda tells me partial collections mess up the heap? If so, I wouldn't be
surprised about ergonomics surprises.

Thanks,
-Aleksey