[gclist] ref-counting performance cost

[Geetha Manjunath]

> I take it they were allocating so much memory that you would have run
> out of core if you hadn't GCed?
>

Yes.

> Can you give some more details on the implementations and the figures?
> - Did your applications all really spend 1/180th of their time in the GC
>   in the worst case (i.e. 300 ms out of every 60 seconds?) or am I
>   misunderstanding the graph?

Yes. This was mainly for the Volano Server application without Ref Cnting.There were
many short lived objects that could be potentially freed by a Ref Cnt GC. Note that
this reduced to about 100ms with Ref Cnt on.

> - Was the ref-counted version a ref-counting optimization to a
>   mark-and-sweep algorithm?  (The legend seems to imply so.)

No, actually, we had a model where we could enable either or both Ref Cnt &
Mark-Sweep GC. Set variants of mark/Sweep precise, non-precise, incremental, etc..

The results are shown when both Ref Cnt (with immediate free- not delayed free) and
simple precise Mark Sweep GC were ON.

> - How did you measure the data --- with timer interrupts?  What was
>   considered to be "in the GC" in each case?

We hooked up timer calls in our JVM - basically timed them at the entry and out ( did
not allow a context switch).

- What were the VolanoMark results?
    Don't remember really :-( But we had an NS486 embedded board that was pretty
slow).

> - Why didn't the ref-counting GC free all the garbage?  Were you using
>   a different definition of "garbage" than the pointer-unreachability
>   one?

Because of cycles of objects - the ref cnting was a simple one too.

regards
Geetha