Shenandoah barriers study

[Aleksey Shipilev]

Hi,

Studying the Shehandoah runtime interface by the most convenient means
for me -- through benchmarking and studying hot disassembly -- and
building the repertoire of interesting code scenarios to improve, here:
  http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/

Runnable JAR, driven by JMH:
 http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/benchmarks.jar

Quick usage:
 $ java -jar benchmarks [name-regexp] [-prof perfasm]

Interesting cases:

 *)
http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/src/main/java/org/openjdk/shenandoah/acmp/ACmpBarriersRandom.java

  Potential improvements:
   a) reuse the null pointers and jump over the read barrier on null?
(Roland has a patch that does this, but it regresses the benchmark [1])
   b) jump over the second cmp on "==" path.

 *)
http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/src/main/java/org/openjdk/shenandoah/acmp/ACmpBarriersKnownNew.java

  Fun: the evidence how the read barrier *improves* performance. x86
performance model is weird.

 *)
http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/src/main/java/org/openjdk/shenandoah/reads/ReadBarriersArrays.java

  Reading off the primitive array is okay, even though we have a read
barrier on a critical path. That is, unless Shenandoah nose-dives on a
small heap.

 *)
http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/src/main/java/org/openjdk/shenandoah/reads/ReadBarriersFields.java

  Implicit NPE check folding failed with compressed oops.

 *)
http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/src/main/java/org/openjdk/shenandoah/reads/ReadBarriersCachePressure.java

  Was concerned that accessing the forwarding pointer before the object
is touching an additional cache line. Does not seem bad, need more analysis.

 *)
http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/src/main/java/org/openjdk/shenandoah/scenarios/LinkedListTraversal.java

  This is one of the adversarial programs. Even in
the worst case, this gives around 25% hit, and gets amortized quickly as
we add work.

 *)
http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/src/main/java/org/openjdk/shenandoah/writes/WriteBarriers.java

 Basic write barrier stuff:
   a) non-implicit null checks -- probably can't fold nicely?
   b) packing/unpacking of source reference to do a read barrier -- can
probably construct a nice LEA that does this without repacking?
   c) evacuation in progress branch should be out of critical path;

I guess most of these would go away after Roland's barriers rewrite to
plain IR.

Next steps: complete other corner cases for write barriers, and onwards
to CAS barriers. Weird idea of tonight: for weak CAS, we are allowed to
spuriously fail, and therefore Shenandoah may skip retry loop with read
barriers, if caller is guaranteed to eventually pass through the read
barrier.

Thanks,
-Aleksey

[1] https://twitter.com/shipilev/status/773926555496185857