Happy path

Aleksey Shipilev shade at redhat.com
Wed Feb 14 11:01:30 UTC 2018


On 02/14/2018 11:03 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/shenandoah/happypath/webrev.00/

This looks very promising!

*) The change in PhaseIdealLoop::place_near_use seems a generic thing for LSM? I think we better
protect this with UseShenandoahGC, to make backporting story easier. Suggestion:

 Node *PhaseIdealLoop::place_near_use( Node *useblock ) const {
   IdealLoopTree *u_loop = get_loop( useblock );
   if (u_loop->_irreducible) {
     return useblock;
   }
   if (u_loop->_child) {
     if (UseShenandoahGC && useblock == u_loop->_head && u_loop->_head->is_OuterStripMinedLoop()) {
///      ^^^^^^^^^^^^^^^^^^^
       return u_loop->_head->in(LoopNode::EntryControl);
     }
     return useblock;
   }
   return u_loop->_head->as_Loop()->skip_strip_mined()->in(LoopNode::EntryControl);
 }

*) In PhaseIdealLoop::find_unswitching_candidate, put assert(UseShenandoahGC) under the branch?

*) I think the calls to is_evacuation_in_progress_test, is_gc_state_load, is_heap_stable_test in the
shared code rely on returning "false" when Shenandoah is not enabled, e.g. by mismatching the graph.
I wonder if we want to put "if (!UseShenandoahGC) return false" explicitly to those checkers, to
nail this behavior. Or, inspect all the uses in the shared code, and protect with UseShenandoahGC?

Performance: we know WB-sensitive benchmarks that could benefit from this:
  http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-January/004626.html

Spot-checking: Compiler.compiler gets +1%. ScimarkLU.small gets +12%. XmlValidation gets +6.5%.

Let me run more benchmarks to see if there are any regressions. If none, we can push this patch as
is, and then work on other stuff incrementally.

Thanks,
-Aleksey



More information about the shenandoah-dev mailing list