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

Andrew Dinn adinn at redhat.com
Wed Aug 15 11:27:00 UTC 2018

On 15/08/18 11:36, Erik Österlund wrote:
> Thank you for the entertaining reply. I do see your point, and agree.

Well, as I said at the end, ditto (and I think I also agree :-)

> Curious to hear if you agree that my use case sounds painful enough to
> motivate a mechanism like this, or not.
Yes, I think so. This is indeed the case I was thinking of when I said
that I see /your/ point. One or two CPUs back, I spent some while
working through the GC code trying to understand how the various
closures (and their subtypes) get passed around. As a novice reader of
that code I found it was very difficult to track that flow.

By contrast, your proposal will mean that side-effects may get magically
inserted by some caller up the stack. However, if that reduces the
complexity of the current dataflows to a relatively small number of
magic points where behaviour does actually get thus (side-)affected then
I agree that this will serve to minimise the complexity to be grappled
with. So, it's definitely a two way street and in this case it seems
likely to be less congested in your direction.


Andrew Dinn
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

More information about the hotspot-runtime-dev mailing list