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

[Kirk Pepperdine]

On 2012-11-27, at 9:57 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> 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 ?

It's hardware specific.. Linux only (so we can stick to pure Java) and it's only been tested on a limited number of Intel chips. As interesting as it is, we've unfortunately had to pull resources from that project in order to feed other efforts which means it's sitting for the moment waiting for attention.

Regards,
Kirk