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

[Roman Kennke]

Hi Erik,

It might be more useful to push this together with an actual use of the
mechanism. It is not entirely clear to me how this might be useful and
how it is supposed to be used. Plus, it would be dead code until an
actual use of it arrives.

Alternatively, provide an example in comments in behaviours.hpp ?

Thanks, Roman


> 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