• Jason House <jason.james.house gmail.com> Apr 17 2011
• Don <nospam nospam.com> Apr 17 2011
• Fawzi Mohamed <fawzi gmx.ch> Apr 18 2011

Jason House <jason.james.house gmail.com> writes:

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!

I was originally assuming the return type of a pure function was enough to
determine if it wasn't leaky, 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?

Don <nospam nospam.com> writes:

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.


 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.

Fawzi Mohamed <fawzi gmx.ch> writes:

On 17-apr-11, at 21:44, Don wrote:

 [...]
 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.


yes more info is always better, I didn't want to diminish your work,  
but to point toward a general improvement in the GC
My fear is that the overhead of this approach will make it worth only  
for big allocations (getting rid of eventual false pointers), and thus  
only under the programmer control.

Classifying the "allocation potential" of a function might help make  
better automatic decisions.
That is difficult in general  (one can flag alloc in loop with unknown  
length or more than 4 elements as large for example, something that  
would miss recursive allocations), but it would be useful, because for  
those that allocate little could do nothing, or use a fixed stack like  
heap, whereas those that allocate a lot could checkpoint the heap  
(assuming a separate pool for each thread) or use a new pool.

Fawzi