Re: Best Ref-counting algorithms?

=?ISO-8859-1?Q?Christoffer_Lern=F6?= <lerno@dragonascendant.com>
Mon, 27 Jul 2009 11:18:56 -0700 (PDT)

          From comp.compilers

Related articles
[29 earlier articles]
Re: Best Ref-counting algorithms? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2009-07-18)
Re: Best Ref-counting algorithms? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-07-18)
Re: Best Ref-counting algorithms? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2009-07-18)
Re: Best Ref-counting algorithms? gneuner2@comcast.net (George Neuner) (2009-07-21)
Re: Best Ref-counting algorithms? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2009-07-22)
Re: Best Ref-counting algorithms? gneuner2@comcast.net (George Neuner) (2009-07-25)
Re: Best Ref-counting algorithms? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2009-07-27)
Re: Best Ref-counting algorithms? gneuner2@comcast.net (George Neuner) (2009-07-30)
Re: Best Ref-counting algorithms? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2009-08-02)
Re: Best Ref-counting algorithms? gneuner2@comcast.net (George Neuner) (2009-08-03)
Re: Best Ref-counting algorithms? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-08-07)
| List of all articles for this month |

From: =?ISO-8859-1?Q?Christoffer_Lern=F6?= <lerno@dragonascendant.com>
Newsgroups: comp.compilers
Date: Mon, 27 Jul 2009 11:18:56 -0700 (PDT)
Organization: Compilers Central
References: 09-07-018 09-07-039 09-07-043 09-07-054 09-07-060 09-07-066 09-07-071 09-07-073 09-07-082 09-07-090
Keywords: GC
Posted-Date: 29 Jul 2009 08:37:33 EDT

On Jul 25, 8:46 am, George Neuner <gneun...@comcast.net> wrote:
> On Wed, 22 Jul 2009 02:31:06 -0700 (PDT), Christoffer Lernv
>
> <le...@dragonascendant.com> wrote:
>> Even before reading about Cyclone I was playing with the idea of being
>> able to define something similar [to lexically scoped heap regions],
>> for instance being able to explicitly select allocation region, where
>> you then could define multiple heaps and GC them separately. (Perhaps
>> even having ways of merging them, moving from one to another etc)
>
>> That's not quite the same as regions in Cyclone, but perhaps it might
>> be 'good enough'.
>
> Cyclone's compiler does not perform region analysis (per Tofte) to
> direct allocation of program objects to particular region heaps. In
> Cyclone, regions are named entities and allocation of program objects
> from them is under programmer control.


From a performance perspective (I mentioned my wish for predictive GC
performance before), would it make sense to enable programmer
controlled regions rather than pure compiler directed ones?


>> This would then be sort of an alternative to escape analysis which I
>> suppose must be rather conservative. For that reason I suspect it is
>> even harder to do the proper analysis in a dynamically typed language
>> as it is not possible during compile time to determine the exact
>> methods that will be called.
>
> Escape analysis is purely an issue of lexical scoping and whether the
> object may outlive the scope in which it is defined. What form of
> typing the language uses is not relevant ... you are only looking for
> the object to leave the control of the scope chain.


In the case of an OO language with dynamic dispatch, then if I'm not
mistaken it's not really possible to tell what happens to any of the
arguments of a method invocation (including the object itself) at
compile time.


It's only post-fact (when returning from the current scope) one is in
a position to determine is the object will outlive the current scope
or not.


That's why I suggested allocating everything on the stack, as I
suppose that most allocation could safely be done on the stack
(assuming constructor allocation being inlined to the parent scope).


Am I missing something that could enable me to do proper escape
analysis and put allocations on the stack?




/Christoffer



Post a followup to this message

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