RFR: 8209437: Mechanism for decoupling consumers and providers of behaviours

[Erik Österlund]

Hi,

Sometimes we find ourselves passing around context information about how 
to perform a certain operation (e.g. check if an oop is alive, logging 
or tracing, etc). Sometimes such behaviours are provided globally by a 
GC, and sometimes only in local scopes known by the GC. Sometimes it is 
even accessed from mutators.

It would be great to have a general mechanism for decoupling how 
behaviours are provided, from the code that uses them.

In particular, I will need this mechanism to build a new nmethod 
unloading mechanism for concurrent class unloading. Today we have a 
single threaded and a parallel nmethod unloading mechanism. Rather than 
introducing a third concurrent way of doing this, I would like to unify 
these mechanism into one mechanism that can be used in all three 
contexts. In order to get there, I need these utilities in order to not 
make a mess. I have a bunch of other use cases down the road as well.

The ideas behind this mechanism are pretty straight forward. Behaviours 
are provided in different ways by "behaviour providers". The providers 
may be global and local, but come in a strict layering (each provider 
has a parent). So from a given callsite, there is a chain of 
responsibility with behaviour providers. You can use BehaviourMark to 
provide a behaviour locally in a certain scope. There are also global 
behaviours to which a GC at bootstrapping time can add behaviours. If no 
local behaviour was found, the global behaviours are checked as plan B. 
In order to speed up the walk, the scoped behaviour providers also come 
with a lazily populated behaviour provider cache that will take you 
straight to a given provider, effectively skipping through the search 
through the chain of responsibility.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8209437

Webrev:
http://cr.openjdk.java.net/~eosterlund/8209437/webrev.00/

Thanks,
/Erik