Re: Best Ref-counting algorithms?

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

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