[gclist] Stupid compacting collector tricks

[David Chase]

I thought you all might enjoy this; it is relatively
silly.  I'm working on a byte-code-to-native Java system,
and part of the system, is, of course, a garbage collector.
For the moment, it is a straight from-space-to-space
compacting collector.  Aficionados of Java semantics know
that all programmer-visible newly-allocated memory is
supposed to be zero; to get those zeros, we map in new
zero pages, and unmap the old space after we have evacuated
it (this is a great way to detect any unforwarded
pointers).

So, I wrote a little GC-exercising test to check out some
bug tickled by the GC, and then ran it post-bug.  It
happens that I have a 2-processor PC with a boatload
of memory.  For grins, I thought I'd check the processor
and memory utilization while this was running; usually, the
GC's appear as little (or not so little) bumps in the memory
utilization.  Turns out that the GC was not visible, probably
because they were running so quickly.  However, much more
entertainingly, both processors were running at 100%, one of
them 100% user mode, the other 100% system mode, presumably
mapping, unmapping, and zeroing out pages.

David Chase