tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <>
Subject RE: Java databases as alternative to MySQL on OS X Server? (OT)
Date Tue, 29 Nov 2005 23:05:57 GMT
> From: Oded Arbel [] 
> Subject: Re: Java databases as alternative to MySQL on OS X 
> Server? (OT)
> Please read up on your Java memory model. What you describe 
> is a nice abstraction that many Java developers have in their
> mind, but is technically not correct and can't be correct when
> you consider multiple processors, DMA, hyper-threading or even
> just plain old L2 CPU caches.

You have to be careful about what viewpoint you're using.  From a Java
programmer's perspective, as well as actual JVM implementation, what I
said is true (although I left out any discussion of volatility and
visibility of writes in a multi-CPU system).  From a hardware or JIT
implementer perspective, what you said is appropriate, since it applies
primarily to CPU pipelines and other low-level memory writers (not
threads per se), but isn't terribly relevant from a practical Java
programming perspective.  Essentially all high-performance systems have
operated with some variation of these considerations from day one, due
to the potential of asynchronous I/O modifying the instruction stream.
The introduction of write buffers into CPU pipelines twenty-odd years
ago really exacerbated the situation.

> Also please note that JSR-133, once implemented, supposedly makes the 
> whole discussion irrelevant as it forces read/write ordering.

Only for intra-thread actions; for inter-thread, ordering is specified
primarily with regards to entities marked volatile and synchronized

> But AFAIK, only Sun's JVM 5.0 (1.5) implements it and I'm not sure
> its correctness.

Actually, JSR 133 largely reflects what the 1.4 HotSpot JVM had already
implemented.  As you say, the jury is still out on whether all of the
low-level synch points have been covered.

> You are obviously disregarding the fact that Java is a 
> multi-platform environment, and some platforms (notably 
> the Mac OS-X which started the whole thread) does not 
> provide such a mechanism.

The PowerPC instruction set includes lwarx and stwcx for this purpose.
If the JIT in the OS X JVM does not generate code to use these for
object synchronization, it would be seriously deficient compared to all
other commercial JVMs.  Without generating such code inline, any
multi-threaded interactions are bound to be horribly slow.

> Are you an MS-Windows programmer by any chance ?

Only when I can't avoid it.  Started working on multi-CPU systems in
1969, so I'm quite familiar with synchronization and data visibility
concerns.  35+ years of doing software and hardware design on a variety
of platforms, including several patents for various features of our
systems.  Currently responsible for (among other things) the JVM
implementation on our 36-bit ones-complement mainframes (and yes, our
JVM does pass all the compatibility tests).  So much for disregarding
multi-platform issues.

 - Chuck

MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message