GC performance - was Re: [gclist] GC topics

[Charles Fiterman]

> The copying one will:
> - use too much memory, since it will touch twice as much VM as there are live
> objects at every collection.  It will need considerably more physical memory
> than that to avoid paging and to keep GC frequency down.
> 
> The conservative one will:
> - be limited to one platform.
Ports are not hard.

> - accidentally retain too much memory with unpleasantly high probability.

The big problem is not mistaking social security numbers for pointers, 32 bit
address space is in gigabytes while heap space is in megabytes. The big problem
is failing to zero pointers when they can never be used again. This is worse
on a Sparc where execution frames are produced with lots of holes. That is
when you get an execution frame it is likely that lots of old stuff in the
frame will never get overwritten. 

If you are generating your own C you can zero dead pointers. We provide C++ 
pointer wrappers that do array bounds checking and zero dead pointers.

We find that conservative collector leaks are O(1) where O tends to be small. 
Leaks left by program bugs are O(n) or worse where O tends to be large.

> - incur unnecessarily high allocation and collection overheads, especially for
> small objects.

Our users report identical or improved performance. After tuning, designating
leaf objects etc they always report improved performance.

> - touch too much VM during collections, though it won't be as bad as the
> copying one.

The trick is keeping descriptors on separate pages.