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

[Richard Warburton]

> 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