Re: GC statistics (was Re: big project ported)

[Kresten Krab Thorup <krab at daimi dot au dot dk>]

Bryce McKinlay <bryce@albatross.co.nz> writes:

> After a few very un-scientific tests I am inclined to agree with your conclusion
> that gc is the major source of performance problems in libgcj. 

[Perhaps this is one for the FAQ]

This is part of the price paid for the convenience of CNI and the
general gcc backend.  It's a tradeoff for cost-of-development versus
speed. 

These performance issues to be expected from a conservative collector,
such as the boehm system.  An exact collector, which knows exactly
which registers and memory locations are pointers to objects, can do a
much better job because it only needs to scan live objects.  A
conservative collector on the other hand needs to visit all objects in
every gc cycle -- both the ones that are live and the ones that are
garbage.  Experiments show that most objects turn out to be garbage
after a single gc-cycle, so the problem is inevitable.

However, given that the Boehm-collector is so widely available, this
tradeoff makes it "easy" to maintain many ports of gcj, without
substantial and error-prone modifications to the gcc backend.  Further
more, it provides for the convenience of CNI: Java objects can be
manipulated as if they were C++ objects, and the whole integration
with legacy code is much more smooth.

So what can be done?  

One option is to change your coding style, but this is a dangerous
path.  This kind of "optimization" will often turn out to produce code
which is harder to understand and maintain; and thus this should be
done very selectively based on *performance-measurements*, if at all.
Concretely, one thing to do is to introduce object pools and then do
explicit memory management of objects in the pool, but even though
this might improve performance, this is seriously bad since it leads
to all the usual problems with explicit memory managemeent.  Further
more, it may leak, and actually cause a performace decrease when run
on a system with an exact garbage collector, such as hotspot, the IBM
JIT, etc.  Forget that I even mentioned it.

The alternative is to invent a new and very clever garbage
collector. Good luck. 

-- Kresten

 Kresten Krab Thorup           "I like my eggs ploded"
 Department of Computer Science, University of Aarhus
 Aabogade 34, DK-8200 Aarhus N, Denmark
 +45 8942 5665 (office), +45 2343 4626 (mobile)