GC for pure functions -- implementation ideas

Steven Schveighoffer schveiguy at yahoo.com
Mon Apr 18 05:40:02 PDT 2011


On Fri, 15 Apr 2011 18:36:17 -0400, Tomek Sowiński <just at ask.me> wrote:

> Don napisał:
>
>> LEAKY FUNCTIONS
>>
>> Define a 'leaky' pure function as a pure function which can return
>> heap-allocated memory to the caller, ie, where the return value or a
>> parameter passed by reference has at least one pointer or reference
>> type. This can be determined simply by inspecting the signature. (Note
>> that the function does not need to be immutably pure).
>>
>> The interesting thing is that heap allocation inside non-leaky pure
>> functions behaves like stack allocation. When you return from that
>> function, *all* those variables are unreachable, and can be discarded en
>> masse. Here's an idea of how to exploit this.
>>
>> THE PURE HEAP
>>
>> [snip]
>
> I'm far from being a GC expert but I think Java having identified such  
> cases with escape analysis just puts locally allocated objects on the  
> stack.

Full escape analysis requires a non-stanard object format and a  
non-standard linker.  Simply because, escape analysis must be a  
compiler-added attribute, and the linker has to understand that.  We can  
get away with certain things reusing the C linker by doing things like  
name mangling, but escape analysis must add far more annotations  
(essentially tell how parameters and return values are linked).

I think at some point, I'd prefer D to use it's own object format and  
linker, to allow both escape analysis, and to use the object format as the  
import database.  But that isn't likely to come from Walter, I think  
someone would have to build a new compiler.

-Steve


More information about the Digitalmars-d mailing list