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