Re: JVM Usenix paper got rejected

[Jeff Sturm <jsturm at detroit dot appnet dot com>]

Bryce McKinlay wrote:
> > In my opinion the performance is a losing battle.  Java has become big
> > business.  The gcj team simply doesn't have money and resources as e.g.
> > the Hotspot engineers do.
> 
> You think? gcj's performance is already competitive with state-of-the-art
> production VMs on many tests (at least on many of the "real application"
> style benchmarks), and yet the code it produces is, quite frankly, crap. We
> havn't even turned on -O yet for compiling the standard libraries. There
> are dozens of opportunities for trivial optimizations with big performance
> potential that have yet to be tapped.

I'm being deliberately pessimistic.  Some of the toy benchmarks I've run
indeed look promising.  But performance on large-scale Java apps shows a
different picture, at least when I last tried it...

> Unconditional calls to _Jv_InitClass are inserted all over by the compiler.

Yep.  Did you notice gcj generates _Jv_InitClass when calling static
methods in the same class as the caller?  Also, certain system classes
(i.e. java.lang.System) are probably initialized during boot, so maybe
those calls can be removed as special case.

These changes don't seem too hard, but unfortunately there seems to be a
severe shortage of hackers willing/able to work on the gcj frontend.

> Interface calls, instanceof, casts, array assignmnets checks, etc all call
> out into libgcj. often. They should all be inlined. Not only do we save the
> overhead of the call by doing this, but can save a lot of work.

Agreed.  _Jv_AllocObject may be another candidate to be inlined.  It
performs a class initialization (which gcj may be able to eliminate),
allocates memory, and possibly registers a finalizer.  The last step
wastes a memory access at runtime, assuming the vast majority of objects
don't have finalizers.

There's also a redundant check for out-of-memory conditions... right now
both _Jv_AllocObj and GC_gcj_malloc() test the return value of
GENERAL_MALLOC().

> Method inlining: private/static methods, constructors, "super" calls, can
> all be inlined once we figure out some reasonable logic to determine
> whether its worth the space/time trade off in each case. Package-private
> methods can be inlined if we can prove that nothing overrides them (fairly
> trivial). Public methods can be inlined slightly less trivially, if the
> class of the target can be proved at compile time, or if we can determine
> what the class is likely to be and add an instanceof check/branch to
> virtual call just in case.

A great many of constructors are actually empty, but the compiler
generates them anyway and calls them without exception.  In that case,
inlining may reduce the constructor to nothing at all.

> Except for some very obvious bottlenecks (like the old interface dispatch
> code ;-), "us" gcj developers are still concentrating fixing bugs (of which
> there are still many, unfortunatly), and improving the class library in
> preference to spending much time on performance issues. Good library
> support is the most important thing which I hope will bring more users and
> developers to gcj eventually, particularly AWT/Java2D.

All good points above.  Keeping in mind that GCC 3.0 is not a
performance release, focusing on functions and correctness now and
performance later is not a bad strategy at all.

> Bottom line: I don't think gcj performance is a "loosing battle" at all.
> Hotspot _might_ be faster now, but not by a huge factor, and only at the
> expense of vast quantities of memory and big startup times. Sure it has a
> lot of dev resources behind it and sure it is getting better, but I suspect
> that the effort required in order to get each few more percentage points of
> performance is firmly in gcj's favour, for now. And lets not forget the
> significant efforts and resources behind the gcc code generation guys, who
> are making improvements all the time behind the scenes, independently of
> the gcj effort.

The Hotspot team also caused a big letdown when its performance didn't
live up to expectations.  So if we don't brag about gcj, maybe someday
we can catch them by surprise ;)

> > As an experiment I recompiled Sun's javac compiler with gcj and observed
> > better than a 400% speedup over a normal javac while building a tree of
> > approx. 250 Java sources.
> 
> Impressive! Which JVM were you comparing against? Was this a single bulk
> run of javac or were you rerunning it for each file (which would magnify
> the startup cost of traditional VMs)?

It was many individual runs.  But javac's performance may have been
limited by runtime factors anyway... has anybody noticed that libgcj's
classloader is far slower than Sun's when reading compressed .jar files?

> There is a bit of a stigma attached to native java compilers because they
> traditionally prohibit dynamic class loading and other nice java "language"
> features. That reviewer apparantly jumped to this conclusion even though
> there was no mention of such things in the paper. Of course, gcj does not
> suffer from this limitation at all. One day someone will plug a good JIT
> into it (ORP seems a possible candidate) and users won't even need to know
> that they're using a "native" java!

Users may also discover that when e.g. a servlet class is interpreted
but all supporting classes (core runtime, JDBC, etc.) are natively
compiled they won't miss a JIT at all.

That said, I'd love to use gcj on our own production sites.  First, it
must be stable, and it must be fast.  For now we are running Sun's 1.2.2
"Exact VM" on Solaris.  It is quite good.  We can handle millions of
hits over a period of weeks at a time before restarts.  The VM has never
crashed (it has deadlocked twice due to coding errors that have been
corrected) and doesn't seem to leak resources.  It'll take some time
before libgcj reaches that level of stability.

Here's my sieve tests done this morning (gcc 112500, IBM JDK 1.3, RH7)
(median of three runs, high scores are better):

VM/flags	score
---------	-----
gij		  126
java -nojit	  201
gcj -O0		  986
gcj -O1		 3702
java		 4396
gcj -O2		 4473
gcj -O2 --no-bounds-check
		 6041

--
Jeff Sturm
jeff.sturm@commerceone.com