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.
