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

[Erik Österlund]

Ping!

Since nobody has looked at this yet, I snuck in a new cache in that I 
feel happier about than the previous one. It's a cuckoo hash. Now 
looking up behaviours will be blazingly fast and memory efficient. Yay!

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

Thanks,
/Erik

On 2018-08-13 19:05, Erik Österlund wrote:
> 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