dynamic library cost (was RE: libtool, java woes)
Sat Apr 14 08:07:00 GMT 2001
On 13-Apr-2001, Tom Tromey <firstname.lastname@example.org> wrote:
> >>>>> "Jon" == Jonathan P Olson <email@example.com> writes:
> Jon> Does anybody have a feel for the costs of non-conservative stack
> Jon> scanning?
> Jon> Wading through all this mess in a GC would likely be more costly
> Jon> than just conservatively scanning the stacks.
> They did this work so that they could implement a compacting collector
> but still have the compiler generate optimized code. So what they did
> is even more ambitious -- if an object is moved they update the stack
> and registers to reflect this.
> My guess is that it would be cheaper, easier, and probably not much
> worse to simply implement a mostly-copying-or-compacting collector.
> (I have no facts to back up this assertion.)
I think it depends on the application.
Having a compacting collector makes some additional optimizations
possible, at least for single-threaded applications. For example, if you
have a function whose return type is some atomic type such as `int', and
through static analysis (or language properties, e.g. for pure functional
languages) you know that this function doesn't have any side effects,
you know that any heap objects allocated in the function will be dead
when the function returns, so you can save the heap pointer on function
entry and restore it on function exit, thus very cheaply collecting
any heap objects allocated in that function. Prolog implementations
typically use a similar optimization to cheaply reclaim heap on backtracking.
For some applications, such optimizations can often avoid the need to
ever do conventional garbage collection.
Fergus Henderson <firstname.lastname@example.org> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh > | -- the last words of T. S. Garp.
More information about the Java