Embedded and real-time JVMs (Was Re: [gclist] write-barrier implementation in Java VM?)

[David Chase]

At 01:57 PM 11/6/00 -0600, Manoj Plakal wrote:
> > I found out (the hard way...) that a plain and simple stop-the-world
> > approach can be surprisingly effective with small heaps...

I have also seen this.  Copy-and-compact can be startlingly effective
when you have a tiny live set.  The time not spent debugging an
incremental collector (soft references, weak references, finalizers,
phantom references, gag me) can instead be spent figuring out how
to make your copying collector run fast(er).

>         Also, I hear about proposals for GC in real-time JVMs,
>         but isn't it a bit of an oxymoron to have "real-time"
>         and "GC" next to each other, at least for tracing GCs
>         whose run-times are difficult to bound? I guess it
>         does matter on the definition of "real-time".

It does depend on the definition of real-time, but it also depends
on the collector.  For instance, if you know that your copying collector
can move 10 Mbyte/second, and you know that your live set is always
smaller than one Mbyte, and you can tolerate a 1/10 second pause
once per second, then it is a simple matter of ensuring that you have
enough memory available to keep the collection rate below 1 Hz.

If you are willing to dump a little overhead onto load and
store operations, you have a lot more options.  Baker's
treadmill collector certainly seems like a possibility.

David Chase
chase@naturalbridge.com