RFR(M): 8212243: More gc interface tweaks for arraycopy and some other smaller changes in preparation for Shenandoah

Roland Westrelin rwestrel at redhat.com
Thu Oct 18 07:43:15 UTC 2018


Hi Erik,

Thanks for looking at this.

> One goal I have had in the barrier set classes is to not introduce the 
> concepts of pre/post (write) barriers until the ModRefBarrierSet layer, 
> as it is not a concept that is at all shared for our GCs. Therefore, I 
> would prefer if this:
>
> virtual void array_copy_post_barrier_at_expansion(ArrayCopyNode* ac, 
> Node*& c, Node*& m, PhaseIterGVN& igvn) const { } ...to all be moved 
> into ModRefBarrierSetC2. I'm imagining to on BarrierSetC2 only expose 
> something like clone_barrier_at_expansion() that gets overridden by 
> ModRefBarrierSetC2 to do the check if post_barriers are needed, and then 
> call the "array_copy_post_barrier_at_expansion" member function of 
> ModRefBarrierSetC2, that looks like it should also be renamed to 
> clone_post_barrier_at_expansion.

That wouldn't work. The reason for this change is Shenandoah and
ShenandoahBarrierSetC2 is a subclass of BarrierSetC2. I suppose it's not
really a post barrier eventhough other gcs could use that hook as a way
to put their post barrier. We use it to fix references after the copy is
done.


> virtual Node* array_copy_load_store_barrier(PhaseGVN *phase, bool 
> can_reshape, Node* v, MergeMemNode* mem, Node*& ctl) const { return v; } 
> ...I would prefer to pass in the BasicType, and perform the T_OBJECT 
> filtering inside, for symmetry with other similar hooks. Also it beats 
> me that this is strictly speaking a load barrier for loads performed in 
> arraycopy. Would it be possible to use something like access_load_at 
> instead? That would have been fantastic. Or is there a mis-fit, such as 
> not having a GraphKit with memory state? If so, it would be interesting 
> to see what it would take to fix that. I believe that hook could be 
> useful for ZGC cloning as well. Thanks, /Erik

GraphKit is a parse time only thing. So the existing gc interface
doesn't offer any way to add barriers once parsing is over. This code
runs after parsing in optimization phases. In the valhalla repo, Tobias
made a change so we can create a GraphKit at optimization time at places
where we have jvm state. So bringing that would allow the use of
access_load and friends in the arraycopy code. Except it's not a simple
change so I would rather go with what we have here and rework it down
the road.

Roland.


More information about the hotspot-compiler-dev mailing list