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

[David Holmes]

 > *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 sun. part that says "don't use this". You get a warning 
everytime you compile against it and you have to force the compiler to 
let you access it.

David

On 5/12/2012 5:20 PM, Michael Barker wrote:
>>> 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