FAQ update

[Jeff Sturm]

On Wed, 3 Nov 1999, Bradley Schatz wrote:
> 5.3 I have just compiled and benchmarked my Java application and it
> seems to
> be running slower than than XXX JIT JVM. Is there anything I can do to
> make
> it go faster?
>
>   A few things. - Anthony Green suggests:
>          
>          o The java code in libgcj is still compiled without
>            optimization enabled. No good reason why really. Start by
>            compiling it with -O2
>          o I believe Jeff Sturm hacked the gc code to start off with a
>            larger heap size and that made a big difference for him. Now
>            that we have system properties working, we should make a
>            property for initializing this. Jeff, can you offer some
>            guidance here? - 

Some programs that allocate many small, short-lived objects can cause the
default-sized heap to fill quickly and GC often.  With the 2.95.1 release
there is no means to adjust the heap at runtime.  Recent snapshots provide
the -ms and -mx arguments to gij to specify the initial and maximum heap
sizes, respectively.

It is possible to turn on verbose GC output by supressing the -DSILENT
flag during build.  One way to do this is to comment out the line with

#define SILENT 1

from boehm-gc/configure before configuring libgcj.  The GC will print
collection statistics to stdout.  (Rebuilding boehm-gc alone without this
flag doesn't seem to work.)

>          o RE - array accesses. We have sub-optimal runtime checking
>            code, and the compiler is still not so smart about
>            automatically removing array checks. If you're code is ready,
>            and it doesn't rely on them, try compiling with
>            --no-bounds-check.

Also:

Try static linking.  The interaction with boehm-gc seems to incur extra
overhead when shared libraries are used (see Anthony Green's message from
last week on this topic).  On one program that makes heavy use of the
allocator I achieved over 30% runtime performance gain with static
linking.

If your Java application doesn't need threads, try building libgcj using
--enable-threads=none.  Portions of the libgcj runtime are still more
efficient when single-threaded.  This will also allow you to use
the profiler (gprof) on non-threaded Java code (POSIX threads seem to be
incompatible with the gmon stuff).

--
Jeff Sturm
jsturm@sigma6.com