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