RFR(M): 8182471: [MVT] Eliminate redundant value type allocations

Roland Westrelin rwestrel at redhat.com
Wed Jun 21 13:45:13 UTC 2017

> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8182471
> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.20/
> The optimization removes redundant value type allocations by searching
> for a dominating allocation and re-using it to replace the dominated
> allocation. This is done during loop optimizations because the GVN
> version of is_dominator() and also MemNode::all_controls_dominate()
> are not strong/good enough. To find candidate allocations, we now keep
> an edge from the ValueTypeNode to the AllocateNode (see
> ValueTypeNode::allocate()) and let GVN take care of merging identical
> value type nodes. In ValueTypeNode::remove_redundant_allocations() we
> then check for ValueTypeNodes with multiple AllocateNodes and
> eliminate redundant ones (see test85-86).
> I also added code to recognize cases when we copy a value type by
> "manually" loading its field values from memory. In this case, we can
> re-use the oop (see test87-90) and avoid allocations.

Is this what this code does:

 462   if (!is_allocated(phase)) {
 463     // Check if this value type is loaded from memory
 464     Node* base = is_loaded(phase, type()->is_valuetype());
 465     if (base != NULL) {
 466       // Save the oop
 467       set_oop(base);
 468       assert(is_allocated(phase), "should now be allocated");
 469     }
 470   }


I suppose val77 in the test case should be renamed.

When we discussed this privately, you said that before allocating we
have a runtime test to verify the value was not yet allocated and that
that runtime test got in the way of your optimization. Did you find a
way around that problem?


More information about the valhalla-dev mailing list