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

Doug Lea dl at cs.oswego.edu
Sun Nov 25 14:02:08 PST 2012

On 11/25/12 16:22, Kirk Pepperdine wrote:

> I'm completely in agreement that there are some applications where this
> optimization is necessary. That said, I've more fundamental concerns with
> respect to this API. Traditionally the JVM has steered away from having
> developers hint at optimization as these optimizations have typically been
> ill thought out. My mantra has always been, measure, don't guess. WIthout
> denigrating any group of developers I would say that very very few know how
> to get the measures to even start to understand how to apply this
> "optimization". I would suggest that it would be better to leave the
> application of this optimization to HotSpot and the JIT compiler.

This is a common reaction, but ...

As witnessed for example by C11/C++11 standards (that support
better ways of obtaining alignment and padding), memory contention
issues are increasingly part of core library and lower-level programming,
in any language. Naively, one might hope that HW memory controllers,
OSes, and/or VMs could sense problems and take evasive action, but
no practical techniques for doing so are known. If JDK/Java takes
the position that it is best to hope for miracles, developers
who need this functionality to create libraries and frameworks
will eventually choose to abandon the platform. Which might be
OK if your goal is to hasten the COBOLization of Java. But
most people seem to want Java to remain a broad-spectrum language,
in which case, it cannot adopt policies that apply to only 99.9%
of the spectrum.

(BTW, stay tuned for other VM support proposals along these lines.)


More information about the hotspot-dev mailing list