[jmm-dev] jdk9 APIs

Paul E. McKenney paulmck at linux.vnet.ibm.com
Fri Aug 14 18:17:20 UTC 2015

On Fri, Aug 14, 2015 at 01:57:41PM -0400, Doug Lea wrote:
> On 08/14/2015 11:36 AM, Paul E. McKenney wrote:
> >Well, if you change your mind about being consumed by analogs of consume,
> >please see the attached revision of C++ working draft N4321.  ;-)
> Thanks.
> My proposal to just introduce loadLoadFence(ref) (which further
> simplifies VarHandle.getDependently(ref)) was based in part
> on Section 3 (of the last version of N4321 I'd seen), that
> mentions and dismisses the idea of forcing layer-by-layer
> use of something similar in extended dependency chains.
> Without an OS kernel full of prior users/code to deal
> with, this seems to minimally suffice. Especially since in
> Java, programmers are more willing to use tools that might help
> automate tiered fence placement. Yes?

My guess is that this is Section 3.5 ("Linux-Kernel Dependency Chain
Length"), the final paragraph of which reads as follows:

	Again, although a great many dependency chains in the Linux
	kernel are quite short, there are quite a few that spread both
	widely and deeply. We therefore cannot expect Linux kernel
	hackers to look fondly on any mechanism that requires them to
	decorate each and every operator in each and every dependency
	chain as was shown in Figure 8. In fact, even kill dependency()
	will likely be an extremely difficult sell.

Given that you don't have existing code and assuming use of
fence-placement tools, layer-by-layer decoration might be OK.

The tools propagate the layer-by-layer decoration from the head
of the dependency chain or some such?

							Thanx, Paul

More information about the jmm-dev mailing list