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

[Zhengyu Gu]

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
>