[gclist] gclist is still alive but not very active
Wed, 5 Nov 1997 10:05:32 -0800
On Nov 5, 10:28am, Simon Spero wrote:
> Ok, here are two questions to chew on :-)
> 1: How do conservative garbage collectors for un-cooperative languages
> degrade over time when used in extremely long-lived server processes?
That's of course a hard question. I would argue that we don't even have
complete answers to that question for malloc/free programs. Current evidence
suggests that fragmentation should remain minor for a good nonmoving allocator.
But I don't know of many measurements of long running server processes.
My experience with pointer misidentification is that its usually not a problem.
In the cases of which I'm aware for which it was a problem, it was easily
detectable. It was also easily remedied with a minor source change once the
problem was identified. The real issue at the moment is the lack of widely
available tools for identifying such things.
This is consistent with my intuition. The leaks from pointer misidentification
remain bounded so long as you don't get into a situation where the average leak
introduces more than one additional leak, due to misidentified pointers in the
leaked object itself. That rarely happens. When it does, there's an
exponential at work, and things diverge fairly quickly. (In real life things
aren't quite that simple because only certain phases might provoke the bad
All of this is good, in that it means that it's fairly easy to test for
It's also consistent with real experiences. Cedar worlds at Xerox PARC stayed
up for long periods with a conservative collector. When they did crash it was
for other reasons (e.g. power failures). Some Xerox high end printers were
Cedar-based and used a conservative collector. As far as I know, they are
quite stable for long periods of time. I saw no evidence of growing leaks or
fragmentation. (The allocator in our GC does have a bit of a problem with
large block fragmentation. But it doesn't seem to get worse over time. It's
> 2: Why are there no commercial conservative garbage collectos for Linux?
Perhaps someone from Geodesic Systems can comment. My impression is the reason
is the same as for the lack of good tools to analyze memory retention in GC
environments: too much to do, too little time.