JEP 171: Fence Intrinsics

[Kirk Pepperdine]

Hi Doug et all...

I've been thinking about these intrinsics/annotations and I've been wondering if it would be worth exploring somehow setting up intrinsics to allow access to the MSRs? With better access to MSR, people might have a better chance of using measures to sort out strange effects due to unfortunately alignments of data in caches.

The source of my objects to these methods is that they can currently only be applied speculatively. As Mike Barker pointed out, he's hacked up access to these registers for Mac's and I and some others have worked up a library for Linux (via the device drivers). But given that all that is really needed is a thin C++ wrapper over a small amount of assembler, it would be so much easier to support this either in the JVMTI or in s.m.u. Down side is that you do need to fix permissions to get this to work and this is all very processor specific and difficult (or practically impossible) to generalize across processors. That said, if the decision has been made to open up access to fencing and padding and other CPU tricks, I'd argue that we need to consider opening up a way to measure the effects.

Regards,
Kirk
On 2012-12-03, at 6:54 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 12/03/12 12:45, David Chase wrote:
>> Is this the right place to comment on this? I think these should not go in
>> Unsafe; fence intrinsics belong with compareAndSet in j.u.concurrent.atomic.
> 
> They cannot. The methods cannot be spec'ed using only the concepts
> in the JLS/JMM. So they are not "Java methods", but "JVM methods".
> (This is the same rationale for placing @Contended in sun.misc.)
> Someday, a serious effort is needed to enable rigorous specs
> of core intrinsics along these lines (possible even with a
> Java-level JMM memory model overhaul). But I don't think anyone
> wants to hold these methods hostage for years until this happens.
> 
> -Doug
> 
> 
>