RFR: Load reference barriers

[Aleksey Shipilev]

On 2/14/19 5:45 PM, Roman Kennke wrote:
> Webrev:
> http://cr.openjdk.java.net/~rkennke/load-ref-barriers/webrev.00/

Whoa, impressive stuff!

What's the plan with this? I say push it to sh/jdk, let it pass testing, stabilization, cleanups,
and then proposed it upstream week(s) later? This would give us automatic webrevs against upstream,
the clear binaries for comparison (basically, jdk/jdk vs sh/jdk) and the patch would not bitrot as much.

I have eyeballed generated code on some interesting benchmarks and it looks clean. It also seems to
pass hotspot_gc_shenandoah for me.

Comments:

 *) Does this mean we execute LRB before SATB enqueue? That means, SATB drainers in
concurrent/traversal may skip the LRB resolution?

 *) There is new include in .ad, why?
     26 #include "gc/shenandoah/c2/shenandoahSupport.hpp"

 *) Why _claim_strong here?

   class ShenandoahEvacuateUpdateRootsTask : public AbstractGangTask {
     ...
      CLDToOopClosure clds(&cl, ClassLoaderData::_claim_strong);

 *) Looking at ShenandoahRootEvacuator::process_evacuate_roots: we are now pre-evacuating most roots
now? Is this to avoid putting LRB when accessing those roots from VM code? I thought this would be
handled by barrier set.

 *) Debugging leftover in node.cpp?

  86     if (Compile::current()->method() != NULL) {
  87       os::message_box("xxx", "yyy");
  88     }

 *) phasetype.hpp: we would need better name for PHASE_CUSTOM...

There are minor corrections from my side, here:
  http://cr.openjdk.java.net/~shade/shenandoah/lrb-shade-fixes.patch

-Aleksey