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

Richard Warburton richard.warburton at gmail.com
Sun Nov 25 16:51:35 PST 2012

But without this we have to resort to manually padding fields to try and get the desired affects. And that makes numerous assumptions regarding normal field layout etc, that are VM dependent.

So which is worse: a) providing an advanced API that the average programmer won't know how to use and could easily misuse (if silly enough to mess with things they don't understand); or b) having library/application writers introduce Java-level field padding that makes various assumptions about the underlying VM ? I think (b) is worse.

Hey,

Firstly thanks for achieving progress on JEP 142. I'm sure everyone on the community side appreciates the effort going into it. I've basically got two points to make, a: there are historical comparisons for this kind of API, b: evidence from the field about devs.

One point of historical comparison to consider is System.gc(). Something that I'm sure many developers have encountered is an overly zealous usage of this function by people who don't understand the way that their GC works or an understanding of the full effects of calling this specific function have. I suppose its an open question as to whether in an ideal world this would have been removed from Java or not, but I think its something that you should consider as a point of comparison when exposing specific performance tweaking characteristics to the user.

On Saturday I gave a talk to a small, but packed, room of Java Devs in London about CPU Caching performance. I talked about using MSRs to measure caching behaviour and described false sharing as a potential problem and the available solutions. (Great timing on the JEP btw!) With hindsight I should have anticipated this discussion on the list and questioned people more about whether they knew or understood the issues beforehand.

My impression of the audience was the overwhelming majority of them hadn't encountered the issue before. In fact I'd say only a couple of people had really thought through this kind of issue before. The first audience question I got was what kind of company used this level of optimisation and analysis for their production code. The only people I've met who talk about false sharing and field padding are people who actually understand their CPU Caching well enough to not abuse the feature. I've met lots of people who say lots of things about Garbage Collection. A few low proportion are sensible,

The London market isn't devoid of people who care about performance issues either. Some of the London Java Community's best attended talks are on performance related topics such as tuning.

In conclusion Kirk is 100% correct to worry about this kind of feature and System.gc() suggests that there are Dragons to avoid, but I think so few people understand this issue enough to even realise there's a benefit to fiddling.

I'm sure many other people have interacted with a wider audience than me, and I imagine they might have anecdotal evidence about abuse of this issue. Has anyone ever encountered code where a developer has padded a field in order to avoid contention issues and badly messed up in the same way that System.gc is abused?

regards,

Richard

More information about the hotspot-dev mailing list