[gclist] ref-counting performance cost
Wed, 30 Aug 2000 15:49:57 +0530
> I take it they were allocating so much memory that you would have run
> out of core if you hadn't GCed?
> 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
> - Why didn't the ref-counting GC free all the garbage? Were you using
> a different definition of "garbage" than the pointer-unreachability
Because of cycles of objects - the ref cnting was a simple one too.