RFR (S) 8222766: Shenandoah: streamline post-LRB CAS barrier

Roman Kennke rkennke at redhat.com
Tue Apr 23 10:52:07 UTC 2019


>> Wait a second. We had this problem before: there *can* be from-space stores. Object-arraycopy can
>> store from-space refs. It would only be temporary, because post-arraycopy would fix it, but I
>> suspect that it can mess up the CAS. Right?
> 
>> I do have a patch that turns the arraycopy pre/copy/post sequence into a single arraycopy loop, that
>> does indeed only ever store to-space refs. Maybe worth to finish it?
> 
> Yes. Maybe a simpler version that does the array fixups in-place before copying it.

I tried that. I don't think it is simpler. And I also don't see what it 
might gain.

> Please link that
> RFE as the blocker for this one?

Done:
https://bugs.openjdk.java.net/browse/JDK-8222859

>> Also, this is not really related to LRB. It would work just the same pre-LRB.
> 
> It kinda does. Before LRB we could store the to-space ptr on normal path: for example, storing the
> reference that slipped through store-val barriers due to the concurrent race with evacuation
> updaters.

Right. This also implies that it's not enough to do RB-like-resolve in 
the arraycopy loop in JDK-8222859.

> This new code relies on assumption that nothing ever stores to-space ptrs anywhere, as LRB
> makes sure nothing is able to get the from-space ptr.

Yes.

I will brush my fix for JDK-8222859.

Roman


More information about the shenandoah-dev mailing list