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

[Michael Barker]

>> I don't mean to add insult to injury, but I think there is yet another
>> restriction that we should place this annotation under, in its current
>> residence
>> of sun.misc.
>>
>> The annotation must be documented as being a no-op when it occurs inside
>> class
>> files that are loaded outside the boot class path.
>>
>> This is consistent with comments made by several other people, that these
>> tools
>> are intended, at least at first, for developers of core classes.  This is
>> also
>> consistent with Unsafe, which (however popular it is) is designed to be
>> used
>> core classes only, on the BCP (boot class path).[1]

*sigh*.

> I'm basically OK with this.
> (Which in juxtaposition with Kirk's post says: Yes, some of
> us need these things so desperately that we are willing to
> live with ridiculous restrictions.)
>
> I do worry about the tiny community of "external" low-level
> Java hackers that I should stick up for though. (Examples:
> The Disrupter and Akka folks, those doing in-house financials and
> analytics.) Experience shows that they are also willing to go
> through ridiculous hurdles so they can write high-performance
> software on JVMs. 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.  For the rest I'd fall back
to doing the padding manually and just pray that Hotspot doesn't
remove my additional fields or pay the cost of the indirection off to
an array (or switch to C#[1] ;-).

Here's were I'm confused by the idea of restricting it's use to core
libraries:  I'm going to do it anyway!  And I'll do it in horrible
ways that the VM has no chance of optimising, because it has no idea
about the intent.  I'll pessimistically add additional padding to
cover the worst case as we don't know the cache line size nor can I
allocate the field aligned on a cache line boundary.  If only there
was a way to tell the VM what I really wanted...

Mike.

*Personally I don't think that sun.misc means anything at all.
There's nothing in the name that suggests to me that it shouldn't be
used.  It's the "Unsafe" part of sun.misc.Unsafe that provides the big
hint to the user.

[1] http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.structlayoutattribute.aspx