performance problems

[Kresten Krab Thorup]

Jeff Sturm <jsturm@sigma6.com> writes:

> One thing I discovered that could affect others testing libgcj
> performance is that synchronized blocks in libgcj rely on pthread
> mutexes, which (at least on Linux) spin forever in a yield loop; they
> never go to sleep before they grab the lock.  So long-term synchronized
> blocks should be avoided in favor of higher-level mechanisms based on
> wait/notify.  (Anyone know what the JDK does?)

I know something about how hotspot does it.  They have some pretty
nify techniques, which are unfortunately patented.

First, the monitor structure is always stack allocated, so it doesn't
take up space. This is fine since Java programs always have
block-structured synchronization.  The new JVM spec allows a VM to
enforce this at verification time, even though it is really a runtime
issue if monitor_enter and monitor_exit instructions are nested
correctly.

Secondly, the gc header is shared with the pointer to the monitor.
While an object is locked, the gc header for that object is copied to
the monitor structure on the stack.  

Since they have a moving garbage collector (or rather collectors),
they also need to keep the identity hash in a header field. 

There is also an upcoming paper on oopsla on yet another technique
developed for the "exact vm", a different name for Sun's "production
release" for sparc.  This technique is developed in coopeation between
Sun and some japanese university, so this might be free.

-- Kresten

 Kresten Krab Thorup, Ph.D. Candidate
 c/o Yonezawa Laboratory
 Department of Information Science   
 The University of Tokyo             
 7-3-1 Hongo, Bunkyo-ku, Tokyo 113 Japan
 Fax: +81-(0)3-5689-4365	 
 Phone: +81-(0)3-5841-4118
 Mobile: +81-(0)90-3693-5715