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

[Doug Lea]

On 12/05/12 02:20, Michael Barker wrote:

>> But a *guarantee* of no effect might be crossing
>> that line. Any ideas?
>
> As part of the tiny community (I'm the current lead developer of the
> Disruptor), I would really like this tool to be made available
> directly (don't really care what package it's in*, I use the Unsafe
> already).  If this annotation was unavailable to me, then a
> significant portion of my use cases would be covered if the value
> field in AtomicLong was marked @Contended.

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.

>
> Here's were I'm confused by the idea of restricting it's use to core
> libraries:

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.

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.

-Doug