[gclist] GC performance comparison for various JVMs

[Boehm, Hans]

Tom Tromey wrote:

> libgcj adds a new mark proc that knows how to mark Java objects.
> These objects are scanned precisely.  Is that what you mean?

It looks like I misidentified the issue.  On closer examination, it looks
like the problem is probably in two places, both related to the GC/gcj
interaction.  (This is based on using gdb and ^C as a profiler.)

- The mark procedure call is relatively slow, and it does too much work.  It
would be nice to get all real procedure calls out of the inner mark loop,
especially if they cross dynamic library boundaries.  We should talk
off-line about whether there's a way for the collector to directly pick up a
bit map from the class object, at least in the common case.

- Similarly, it would be nice to compress the allocation path.  There are
too many levels of procdure calls, and I think a couple of things could be
precomputed statically with the right hooks.  We should talk more about this
offline.

Hans