RFR(XL): 8224675: Late GC barrier insertion for ZGC

[Roland Westrelin]

Hi Nils,

> Webrev: http://cr.openjdk.java.net/~neliasso/8224675/webrev.01/

zBarrierSetC2.cpp: typo loadbarrers line 756

lcm.cpp:

void PhaseCFG:: call_catch_cleanup(Block* block) {

space after ::?

loopnode.cpp:

Node *u

I thought the usually recommended style was:

Node* u

loopnode.cpp:

Do we really need a new entry in the gc api for barrier_insertion()
couldn't this go under optimize_loops()?

memnode.hpp:

 168   enum LoadBarrier {
 169     UnProcessed     = 0,
 170     RequireBarrier  = 1,
 171     WeakBarrier     = 3,  // Inclusive with RequireBarrier
 172     ExpandedBarrier = 4
 173   };

Shouldn't that be abstracted away through the gc api somehow?

zBarrierSetC2.cpp:

typo (witch):

981     // For each load use, see witch catch projs dominates, create load clone lazily and reconnect

In fixup_uses_in_catch() wouldn't you need to deal with phis the way you
do in call_catch_cleanup_one():

1019     // We found no single catchproj that dominated the use - The use is at a point after
1020     // where control flow from multiple catch projs have merged. We will have to create
1021     // phi nodes before the use and tie the output from the cloned loads together. It
1022     // can be a single phi or a number of chained phis, depending on control flow

Is there a chance that a load would be processed by
fixup_uses_in_catch()? I see call_catch_cleanup_one() is where they are
expected to be handled but you only go there if
load->is_barrier_required() is true. So could you have a load for which
is_barrier_required() is true have a use for which is_barrier_required()
is not true and both of them be in the catch block?

Roland.