> From: Oded Arbel [mailto:[EMAIL PROTECTED] > 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 operations. > But AFAIK, only Sun's JVM 5.0 (1.5) implements it and I'm not sure about > 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 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
