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

[Remi Forax]

On 11/27/2012 07:33 AM, Kirk Pepperdine wrote:
> Hi Vitaly,
>
> My comment about unsafe was a bit tongue in cheek. If this is to be done, than it seems the sensible package would be j.u.c. As for mothering developers, this isn't about mothering developers, it's about moving forward in a way that fits with Java's way of doing thing. I still stand by my previous email that this"optimization" is unsfe (hence the pun). I'll start with some questions... how would a developer know when to apply this annotation. Or conversely, once applied, how would a developer know if the padding now was de-optimizing the run time?
>
> I'm sure that there are some (micro???) benchmarks  (have they been published so we can look at them?)  some where in Oracle that demonstrates which means this has been a very interesting and useful experiment. It has demonstrated that there is some value in somehow adapting code to deal with conditions that are specific to a particular runtime configuration. That said, Java has been about making difficult things reachable to average developers. HotSpot has been about adapting code to particular run time conditions. Thus I would argue that this annotation runs counter to both purposes.
>
>  From a business perspective I'd be thrilled to have this annotation appear in the JDK. I've built tooling that nicely detects conditions when padding out a cache line would solve some degenerate condition such as false sharing. I'd be thrilled because the tooling is completely safe to run in a production environment and this annotation will create a very nice market for it. I which is exactly where it would need to run to properly detect the need or impact of the "optimization". t would replace all of the business I lost when CMS started to collected perm space by default. Ok, that was another tongue in cheek also because I did speak to Tony about all the field work I was doing just getting people to set two values to true.  My point here is that if I have been able to develop this type of tooling it suggests that it is possible (in fact I'd argue some what easier) to develop it for the JVM. This way we would convert a difficult to understand, potentially fragile optimization into one that becomes adaptive to the runtime conditions that it finds it's self in. This is not full profiling in the traditional sense of profiling. It's targeted and it's cheap.
>
> So before dropping an annotation into the JDK that will be with us forever, I would suggest that we explore ways having the runtime detect and adapt.

Does your tooling works with G1 ?

>
> Regards,
> Kirk

cheers,
Rémi

>
>
>
> On 2012-11-26, at 8:43 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>> I don't see what burying this in sun.misc really accomplishes.  Look at Unsafe - it's still widely used except have to jump through reflection hoops.  Also, sun.misc is apparently going away in java 9.
>>
>> I also don't understand the reasoning behind trying to "prevent people from shooting themselves in the foot" - we should consider java developers as responsible adults.  Nobody is forcing anyone to use this annotation.  Otherwise, we should throw out GC tuning knobs, JIT tuning knobs, weak/soft/phantom refs, finalizers, thread locals, direct byte buffers, etc.  This entire "java devs are too immature/dumb/irresponsible/etc" sentiment is ridiculous, IMHO.
>>
>> By the way, if you think only Doug/Cliff Click/etc are using Unsafe, then don't tell Cassandra/Hbase developers :).  Cassandra goes as far as using pluggable C heap allocators (accessed via Unsafe behind the scenes) to allocate off-heap memory - this is in addition to using unsafe comparators for byte arrays, and other "tricks".  That's the price of admission when trying to squeeze perf ...
>>
>> Sent from my phone
>>
>> On Nov 26, 2012 2:19 PM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:
>> Actually, sun.misc.Contended right beside sun.misc.Unsafe doesn't sound like such a bad idea.
>>
>> -- Kirk
>>
>> On 2012-11-26, at 8:08 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>>
>>> On 11/26/12 13:40, Aleksey Shipilev wrote:
>>>> On 11/26/2012 09:35 PM, Remi Forax wrote:
>>>>> On 11/26/2012 05:44 PM, Aleksey Shipilev wrote:
>>>>>> On 11/26/2012 08:22 PM, Doug Lea wrote:
>>>>>>> One small suggestion to slightly appease the nanny-state folks.
>>>>>>> How about burying the annotation one lever deeper to
>>>>>>> java.util.concurrent.atomic.
>>>>> +1
>>>>>
>>>> Still fail to see the rationale about this.
>>> All things considered, I'm back to agreeing with you --
>>> Just j.u.c.Contended
>>>
>>>>> I think you should re-write the javadoc ...
>>> The Contended.java file and its javadoc in Aleksey's webrev is just a
>>> placeholder to get things moving. We expect to solicit
>>> reviews in the usual way (mainly on concurrency-interest list)
>>> for a version that will make it into JDK8.
>>>
>>>> I.e.
>>>>
>>>>      @Contended
>>>>      public class ValueClass {
>>>>           private int field1;
>>>>           private int field2;
>>>>           private int field3;
>>>>           private int field4;
>>>>      }
>>>>
>>>> is the shortcut for:
>>>>
>>>>      public class ValueClass {
>>>>           @Contended("theSame") private int field1;
>>>>           @Contended("theSame") private int field2;
>>>>           @Contended("theSame") private int field3;
>>>>           @Contended("theSame") private int field4;
>>>>      }
>>>>
>>>> That is, all the fields would be densely-packed, but will be padded as
>>>> the group. Note that it is not the same as:
>>>>
>>>>      public class ValueClass {
>>>>           @Contended private int field1;
>>>>           @Contended private int field2;
>>>>           @Contended private int field3;
>>>>           @Contended private int field4;
>>>>      }
>>>>
>>>> Maybe that is already confusing enough to drop class-level annotation?
>>>> What do others feel about this?
>>> I think that the most common and most-recommended case will be class-level,
>>> so it should be kept. We can work on the usage advice in the javadocs.
>>>
>>> -Doug
>>>
>>>