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

[Roman Kennke]

Am 13.08.2018 um 13:13 schrieb 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.
> 

That looks even better. Please push that if it passes testing.

Thank you!
Roman