Re: FAQ update

[Tom Tromey <tromey at cygnus dot com>]

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

Bryce> I wonder - is this overhead due to calls between application
Bryce> code and the shared library, or between the libgcj and libgcjgc
Bryce> libraries? If it (or part of it) is the latter, is there any
Bryce> reason why the two libraries shouln't be merged?

I don't remember answering this.  Merging is a last resort, since it
is fairly ugly.

The first try will be moving to a bitmap marking scheme (no
cross-library calls for marking most objects -- the marking is done
in-line in the GC), followed by reducing the length of the allocation
path.  Many thanks to Hans Boehm who has helped a lot in this process.

Bryce> Although it is nice in theory to have everything modular and
Bryce> the GC implementation swappable at runtime, in reality this
Bryce> isn't going to work - libgcj.so depends on private
Bryce> implementation details of the collector (as anyone who has
Bryce> tried to change the GC configuration without recompiling libgcj
Bryce> as well will know).

Oh, definitely.  We've always known that pluggable GCs will almost
certainly require recompilation.  I don't think this is a big deal,
but that really reflects Cygnus' embedded bias.  For Linux boxes it
might very well be a big deal.

Tom