[15] RFR(S): 8235332: TestInstanceCloneAsLoadsStores.java fails with -XX:+StressGCM

Roland Westrelin rwestrel at redhat.com
Wed Jan 15 10:08:17 UTC 2020


>> If there's no GC barrier then:
>> 
>> Node* control_proj_ac = bs->step_over_gc_barrier(proj_in->in(0));
>> 
>> control_proj_ac is not a projection, it's proj_in->in(0) so the test
>> below can never succeed?
>
> If there is no GC barrier, then proj_in is a membar with its control 
> input being a control projection from the ArrayCopyNode.
>
> As an example, I have taken the test case TestEliminatedCloneBadMemEdge 
> [1] which does not disable ReduceInitialCardMarks and has no GC barrier. 
> We have the following situation at [2]:
>
> proj_in is 132 MemBarCPUOrder. The original code then looked at the 
> MergeMem 100 input following in(Compile::AliasIdxRaw) which is 101 Proj 
> and its input 98 ArrayCopy. This passes the check.
>
> My fix now directly looks at the control input of 132 MemBarCPUOrder 
> which is the projection 99 Proj coming from the 98 ArrayCopy. This also 
> passes the check.

Ah! Right. I wonder if there's a reason why the current code follows the
control graph (as you do) instead of the memory graph. I couldn't find
one and your change looks good to me.

Roland.



More information about the hotspot-compiler-dev mailing list