Related articles |
---|
Re: Compile-time garbage collection (was Re: Compiler writers will joachim.durchholz@web.de (Joachim Durchholz) (2003-07-17) |
Re: Compile-time garbage collection (was Re: Compiler writers will vbdis@aol.com (2003-07-21) |
Re: Compile-time garbage collection (was Re: Compiler writers will joachim.durchholz@web.de (Joachim Durchholz) (2003-07-23) |
From: | vbdis@aol.com (VBDis) |
Newsgroups: | comp.compilers |
Date: | 21 Jul 2003 21:37:46 -0400 |
Organization: | AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com |
References: | 03-07-122 |
Keywords: | storage, GC |
Posted-Date: | 21 Jul 2003 21:37:46 EDT |
Joachim Durchholz <joachim.durchholz@web.de> schreibt:
>The docs claim that a typical program will overlook less than 1% of dead
>blocks in the latter case.
Fine, but what about overlooking live references? ;-)
>> This can occur e.g. during the evaluation of f(a(), b()), where the
>> results of a() and b() can reside in arbitrary locations in the stack,
>> before f() is invoked.
>
>It's not an arbitrary location, it's the slots for intermediate
>results. These are usually found between the local variables of the
>current routine and top-of-stack.
And that's just a location which deserves detailed description. Consider that
the stack can have any number of layouts (scopes), during execution of a
subroutine. Every evaluation, which pushes intermediate references onto the
stack, will deserve an according description of the current stack layout. The
marker then will have to examine the current address within the subroutine
code, and use it to fetch the according stack description from a list of all
those descriptions. Those stack descriptions also will have to include the
local variables, which may be overlaid for parallel blocks of code.
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.