Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Java databases as alternative to MySQL on OS X Server? (OT)
Date: Tue, 29 Nov 2005 17:05:57 -0600
Message-ID: 
 <AEF3D568DD1D9E428048C592AA164597030F7762@USRV-EXCH4.na.uis.unisys.com>
Thread-Topic: Java databases as alternative to MySQL on OS X Server? (OT)
Thread-Index: AcX1K14PQ6w0yIbHS8So4O7IU+lojwAAKQVw
From: "Caldarale, Charles R" <Chuck.Caldarale@unisys.com>
To: <users@tomcat.apache.org>

> From: Oded Arbel [mailto:oded@m-wise.com]=20
> Subject: Re: Java databases as alternative to MySQL on OS X=20
> Server? (OT)
>=20
> Please read up on your Java memory model. What you describe=20
> 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=20
> 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=20
> 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=20
> multi-platform environment, and some platforms (notably=20
> the Mac OS-X which started the whole thread) does not=20
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org