RFR: 8236732: Shenandoah: Stricter placement for oom-evac scopes

[Zhengyu Gu]

Need to update copyright years :-)

-Zhengyu

On 1/7/20 3:43 PM, Zhengyu Gu wrote:
> Okay.
> 
> -Zhengyu
> 
> On 1/7/20 3:26 PM, Roman Kennke wrote:
>> I'm currently looking at a deadlock with the derby benchmark which
>> involves oom-scopes and new concurrent-class-unloading.
>>
>> Currently, we have sprinkled OOM-evac scopes all over the place:
>> - In the main evac-loop (of course)
>> - In the LRB (of course)
>> - In various places
>>
>> The latter is very questionable and has repeatedly lead to problems in
>> the past. The trouble was usually that some weird path would dive into
>> evacuation with a GC worker, although the oom-scope was already held at
>> an outer scope. It becomes really bad when locks are involved, e.g. the
>> heap-lock, code-cache-lock and recently the per-nmethod locks. This is
>> very deadlock-prone.
>>
>> The way out is to be very strict about where we place the oom-scopes.
>> They should *only* be very close to SH::evacuate_object(), and they
>> should *always* be the innermost scopes, inside any possible locks.
>> Placement must be such that both conditions are rather obviously met.
>>
>> The biggest trouble here is Traversal GC: since it does *both* evacs and
>> other stuff during traversal, it dives into LRB through various paths
>> while GC threads holding the evac-scope. The solution is to only enter
>> evac-scope very closely to SH::evacuate_object() at the expense of doing
>> it quite often during traversal. I prefer to have a clear way to do it
>> though, instead of the mess that we currently have.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8236732
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8236732/webrev.00/
>>
>> Testing: hotspot_gc_shenandoah, the specjvm/derby benchmark that
>> troubled me with deadlock is now looking clean
>>
>> Ok?
>>
>> Roman
>>