[concurrency-interest] Curious: How Java Memory Model is satisfied in JSR166 locks?

Osvaldo Pinali Doederlein osvaldo at visionnaire.com.br
Tue Aug 21 12:27:52 EDT 2007

Matthias Ernst escreveu:
> On 8/21/07, Osvaldo Pinali Doederlein <osvaldo at visionnaire.com.br> wrote:
>> Yes there is black magic - it's in class sun.misc.Unsafe
> I find this an interesting point BTW - this is where the distinction
> between VM and language spec falls apart. Library methods with an
> impact on language semantics should actually be part of the VM
> specification; look how #finalize() made it into the JVMS and
> java.util.ref hasn't.
Well, sun.misc.Unsafe is an implementation detail of Sun's JVM. The same 
can be said of all code inside critical methods of j.u.c classes. As far 
as spec compliance goes, the entire j.u.c could be implemented on top of 
standard Java monitors + volatiles (esp. with the new JMM). Such 
implementation wouldn't be particularly fast, but it would be compliant 
(it's how the backport library targets Java1.4, AFAIK). Or perhaps, 
Unsafe's methods (or their equivalents) could be real JNI calls into 
native code that contains special instructions like CAS. Once again 
performance would suffer (JNI) but you don't need special JVM support 
(intrinsification) to obtain compliance. Specifications (at least 
Java's) don't need to go down to performance requirements. (The closer 
Java specs goes is some O(N) specs, e.g. in collections.) In summary, 
just because there is a public API, like lock(), that requires a 
specific JMM semantics, this doesn't mean that the specification should 
mention how to implement this semantics. Even the language doesn't need 
to provide any standard mechanism to make it possible. Because Java is a 
managed language, there are several APIs that cannot be implemented in 
pure Java per definition.

Other JVMs that are based on Sun code, like the IBM JDK, have the same 
sun.misc.Unsafe class, but they could implement j.u.c and other special 
libraries (e.g. serialization and reflection) with completely different 
code if they wanted to. But I was curious enough to check the latest GNU 
Classpath, and... they have a sun.misc.Unsafe class! But it's a 
clean-room implementation, the methods are different. Only the essential 
stuff is there (park/unpark, CAS, and support for direct access to 
object fields with specific memory semantics). But they probably did 
that just because they can (and do) use all JSR166 sources, which are in 
public domain.


Osvaldo Pinali Doederlein                   Visionnaire Informática S/A
osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
Arquiteto de Tecnologia                          +55 (41) 337-1000 #223

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070821/656027d5/attachment.html 

More information about the Concurrency-interest mailing list