Re: JVM Usenix paper got rejected

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Jeff Sturm wrote:

> > A *lot* of work is happening on this and there are some quite
> > interesting developments. GCJ is one. The potential of HotSpot engines
> > is another and approaches like Jazelle is yet another.
>
> 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.

Just a few examples off the top of my head:

Unconditional calls to _Jv_InitClass are inserted all over by the compiler.
For a start they should all be replaced with the equivilant of "if
__builtin_expect (someclass$.state < JV_STATE_DONE, false)
_Jv_initClass(someclass$)". Secondly init calls should be moved from inside
static methods to the call sites (this requires co-operation from the c++
compiler). Thirdly lots of these can be eliminated at compile time if we
apply some simple rules like "if class is a superclass of this class then
it must be already initialized", "if we already initialized a subclass of
class then it must be already initialized", "if call is to a static method
in this class then we dont need to initialize".

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.
_Jv_IsAssignableFrom doesn't look like you'd want to try and inline it at
first glance, but a bit of compile time knowledge reduces it down to a
fraction of its complexity. The ancestors table and class idt should be
computed at compile time and placed directly in the class object, saving
the extra pointer dereference (only the iindex value and interface idt
actually need to be calculated at runtime). Moving all this logic inline
and getting rid of all the potential side effects will give the gcc
optimizer a lot more to work with.

Value range propagation to eliminate many array bounds checks.

All Math.* calls can be inlined or retargeted directly at __builtin_* maths
functions. The non-strict "new fp semantics" can be implemented, replacing
slow library calls with fast FPU instructions.

Things like thread-local allocations, cache prefetch, and concurrent
marking are all ready and waiting to be switched on in the GC.

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.

Stack based string concatenation, and stack allocation optimizations in
general.

These are just some of the basic things that could be done now. Further out
on the horizon there are many more once we start talking about
whole-package and whole-program analysis/optimization (the later implies
that we sacrifice dynamic loading capabilies, but thats a reasonable trade
off for some applications).

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.

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.

> 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)?

> > Also, I don't think that the usenix people necessarily represent the
> > "java community".
>
> Probably not.  But I suspect gcj would not be popular with many Java
> proponents.  You might say gcj emphasizes Java as a language over Java
> as a platform.  Some would say that's the wrong direction for Java.  The
> Usenix reviewer could have been similarly biased.

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!

> But the real innovation seems to have drained out of Java nowadays, and I
> find myself
> keeping one eye open for something better.

Well, I think its likely we'll see parameterized types added to Java one
day, but realistically an actual implementation is a long way off.

regards

  [ bryce ]