RFR (S): JEP-142: Reduce Cache Contention on Specified Fields

[Michael Barker]

> Mostly as an aside: We wouldn't do this by default for
> AtomicInteger etc, to avoid surprises for existing users,
> but would make available alternate classes that do.

Make's sense.

> I think John's point/view is that if you have components
> that are explicitly in JVMese, not Java (i.e., that use sun.misc),
> then you are by definition providing a "core library" and
> users should be forced to be aware of it by requiring
> a bootclasspath VM switch to run. This would be a less
> controversial idea if it were not for all the cases that arise
> in practice where other factors make it impossible for the
> actual users of the functionality to control JVM startup
> settings. Which ends up making this proposed rule overly
> hostile in its practical effect.

I agree, almost to the point where it wouldn't worth the effort to
produce a JDK8+ specific implementation of the Disruptor (or any other
re-usable library) that used @Contended instead of the manual padding.
 I think users would follow the path of least resistance and use the
one with manual padding.  Admittedly I'm guessing, so I'll definitely
attempt to use this when it comes available and measure the uptake.

A middle ground I could live with would be something like
-XX:(+/-)RestrictContendedToBootClassPath (preferably with the default
as off).  Adding/removing a switch of that nature is operationally
simpler than fiddling with file locations and classpath settings.

> So I think that wording things so as to make no promises
> in these cases (and to not force the VM to make special
> efforts to see if it must ignore @Contended), rather than to
> promise no effect, is the best compromise available.

I can understand the necessity of not speccing the JVM into a corner.
What I'm hoping is that in practice is that by default it will provide
the behaviour that it suggests, i.e. false sharing is prevented on the
areas where I know they could be contented.  I'll just find a way
verify the behaviour before each production release and be able to
document which configurations work.

Mike.