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

David Holmes david.holmes at oracle.com
Mon Aug 20 06:55:21 UTC 2018


Hi Erik,

Sorry but I find this so abstract I can't quite determine what it is 
exactly that you are doing. I suspect I know this pattern under some 
other name/terminology but so far, just looking at the code, I can't 
connect the dots. Could you give some concrete examples of usage please.

Thanks,
David

On 14/08/2018 3:05 AM, 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


More information about the hotspot-runtime-dev mailing list