Re: Compile-time garbage collection (was Re: Compiler writers will

vbdis@aol.com (VBDis)
21 Jul 2003 21:37:46 -0400

          From comp.compilers

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)
| List of all articles for this month |
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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.