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

[Roman Kennke]

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