big project ported

[Tom Tromey]

>>>>> "Steve" == Steven Ashe <ashe@boulder.qms.com> writes:

Is that "boulder" as in "Boulder, CO"?  That's where I live.

Steve> It has lots of C code too, and now has #ifdef CNI / #ifdef JNI
Steve> on all the native interfaces.

That's a bit ugly, I guess.  Someday we'll have JNI.

Steve> ibm-jvm for linux 1.1.8  2.36 sec
Steve> gcj -O2 compiled 2.95.1  7.43 sec

The bad news is that we haven't done much performance investigation or
tuning.

One thing to try would be to profile the gcj-built code and see what
is going on.  This involves building profiling versions of all the
libraries, which is a pain.

Steve> 2) Sometimes, when manually forcing gc, it takes an
Steve> unacceptably long time (many seconds) for the Boehm GC to run;
Steve> 3) sometimes running the gc back-to-back causes the second run
Steve> of gc to 'consume' 2 Mb out of no-where (weird).

Our GC is a fairly old version of the Boehm GC.  Our hacks are mostly
only on the configury side.  One idea would be to get a newer version
of the GC and see how it performs.  Importing a new version of the GC
is on my to-do list, but I don't know when I'll be doing it.  This
might fix your strange GC problems, but I don't know whether it would
help your performance problems.

Lately I've also been talking with Hans Boehm about how to speed up
our own use of the GC.  I don't know when I'd be able to implement his
suggested changes.  This would probably help your performance
problems, but I don't really know how effective it would be.  I don't
have any profiling data to really support the theory that the GC is
the problem.

Tom