GC for pure functions -- implementation ideas

Don nospam at nospam.com
Sun Apr 17 12:44:51 PDT 2011


Jason House wrote:
> Don Wrote:
>> Tomek Sowiñski wrote:
>>> 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.
>> That works for the non-leaky function itself, but it doesn't help for 
>> the functions it calls.
> 
> It'd reduce the use of the pure heap to leaky pure functions called from pure functions. If I understood the original proposal correctly, this would reduce how frequently pure functions have to manipulate the pure stack. I haven't thought through the exception handling case, so I may be completely wrong!

It would definitely help a lot. It just wouldn't catch everything.
It seems fairly difficult though.

> I was originally assuming the return type of a pure function was enough to determine if it wasn't leaky, 

You also have parameters passed by reference.

but now I'm thinking only pure nothrow functions can be non-leaky. That 
might make the stack allocation optimization too rare to be worthwhile?

It might. Although as I mentioned, you can deep-dup any exceptions onto 
the normal gc heap, at the moment they are caught. That deep-dup is not 
performance critical, and in most cases, the dup is simple. But the 
worst case is, the entire pure heap needs to be copied. It might turn 
out to be too complicated to be worthwhile, limiting the scheme to pure 
nothrow functions.
Nontheless I think pure nothrow functions will be pretty common.

Basically, my contribution is this: the compiler can easily work out, 
for each function, whenever it has entered and exited a non-leaky pure 
function. It can make a call into the GC whenever this happens. This 
gives the GC many more potential strategies.


More information about the Digitalmars-d mailing list