Re: performance problems

[Jeff Sturm <jsturm@sigma6.com>]

Tom Tromey wrote:
> Jeff> My benchmark program, a small web server written in java, runs
> Jeff> about 30% faster with gcj than it does with the IBM JDK.  That
> Jeff> was with 2.95 prerelease code.
> 
> Is the IBM JDK a JIT?

Yes.  It's the 1.1.6 JDK recently released for glibc2.1 systems... the
JIT is essentially the same as in their Win32 release.

My HTTP benchmark performed faster with gcj than any Java release I've
tried on any platform.  Finally my Linux machines are outperforming NT
on Java codes!!!

I compiled the benchmark code with -O3, I think...  I also hacked the GC
initialization code to bump the initial heap up to 16MB.  I should
probably send a patch for it.  Does anyone object to an environment
variable, something like GCJ_HEAP_INIT, to set the initial heap size?

> Jeff> One thing I discovered that could affect others testing libgcj
> Jeff> performance is that synchronized blocks in libgcj rely on
> Jeff> pthread mutexes, which (at least on Linux) spin forever in a
> Jeff> yield loop; they never go to sleep before they grab the lock.
> Jeff> So long-term synchronized blocks should be avoided in favor of
> Jeff> higher-level mechanisms based on wait/notify.  (Anyone know what
> Jeff> the JDK does?)
> 
> I don't know what the JDK does.  I was unaware of this behavior in
> LinuxThreads.
> 
> The current thread code in libgcj was designed for simplicity.  I have
> never done any profiling to see how fast or slow it might be.  We can
> change it, even on a per-OS basis (e.g., a Linux-specific
> implementation), if that would help a lot.
> 
> Does the slowness of synchronized blocks contribute greatly to
> slowdowns in real programs?

I think the thread implementation as it stands is very good, as my HTTP
server demonstrates.  I've run some primitive tests to stress the
implementation on both uniprocessor and SMP configurations.  In almost
every case libgcj performs as well as or better than the JDK.

Often spinlocks have little or no impact on execution times.  A big
benefit of the spinlock monitor implementation is that there is
negligible cost to monitorenter/monitorexit when threads are not
competing for a monitor, as in a single-threaded program.  Once I did
take the time to strip every synchronized keyword from a long-running
program that runs in one thread... in the end there was no measurable
difference in execution times.

There are pathological cases where the spinlock monitor becomes
inefficient however... for example, threads that block waiting for I/O
while holding a monitor.  Any other thread trying to enter the monitor
is going to busy-loop at least until the I/O completes, potentially a
very long time.  Another problem is a thread trying to enter a monitor
held by a lower-priority thread that doesn't get a chance to run.  The
mutex code in LinuxThreads detects "stubborn" spinlocks and begins to
nanosleep() to avoid deadlock, but this situation should be avoided.

> Jeff> I should probably mention this to the LinuxThread maintainer,
> Jeff> whoever that is...
> 
> Here is the LinuxThreads home page:
> 
> http://pauillac.inria.fr/~xleroy/linuxthreads/

Thanks; I'll take a look.

--
Jeff Sturm
jsturm@sigma6.com