RFR: Don't re-enter evac-scope in worker-threads when hitting a write-barrier

[Aleksey Shipilev]

On 08/10/2018 06:56 PM, Roman Kennke wrote:
> An early adopter has run into a bug where a GC worker thread would
> attempt to re-enter the evac-scope because it hits a write barrier. That
> path was not trivial to clean up (it went through threads-root-scanning,
> and then attempted to clean up monitors, which would touch mark word and
> thus does a write-barrier.
> 
> The solution that I'm proposing is to always check for worker-thread in
> the usual runtime write-barrier path, and branch to write_barrier_gc()
> when it's a worker thread, which does not use the evac-scope, and
> asserts that it already has entered the scope.
> 
> The slow-paths coming from (potentially hot) c2, c1 and interpreter WBs
> unconditionally use the mutator version.
> 
> http://cr.openjdk.java.net/~rkennke/wb-evac-scopes/webrev.00/

That code duplication would get much worse when we actually optimize the hot-path via JRT. We have
three ways to enter WB, and all these cases need to be optimized:
 1) via JRT, already checked cset, evac-in-progress, etc;
 2) via SBS::WB from Java thread;
 3) via SBS::WB from GC thread;

Having that in mind, I believe the better form for the patch is this one:
  http://cr.openjdk.java.net/~shade/shenandoah/wb-split-mutator/webrev.01/

I can follow-up on that version.

-Aleksey