FAQ update

Thu Nov 4 10:14:00 GMT 1999

A couple of notes on future directions:
- Very recent versions of the GC (5.0 alpha N) behave differently (by
default anyway) with respect to GC triggering. Even in the nonincremental
case, garbage collections are triggered before the heap fills up completely.
Thus starting out with a larger heap size is much less effective. (The heap
size is still factored into the decision about when to start a collection,
but only to a small extent.)
This helps the fragmentation behavior of programs that occasionally allocate
very large memory chunks. Otherwise these tend to get broken up on every GC
cycle.
It sounds like this issue may need to be revisited. There probably should
be a way to provide a larger and fully utilized initial heap.
- I'm not sure there's any real reason (other than a deficiency in the Sun
JDK implementation, and perhaps a Microsoft OS deficiency) for Sun's -mx
option. Isn't that what the shell "limit" command is for?
- I would postpone the discussion about static linking of libgcj and
libgcjgc until the interface is streamlined a bit more. Bitmap-based
marking may help a lot, since it will remove calls between the two during
marking. It may also be possible to change the allocator interface to
reduce the amount of interaction. Linking them statically as a short-term
stop-gap solution is of course a different matter.
Hans
 
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Wednesday, November 03, 1999 8:53 PM
To: Bradley Schatz
Cc: java-discuss@sourceware.cygnus.com
Subject: Re: FAQ update
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