<div dir="ltr">Not only this is desirable but in fact this is REQUIRED to implemented any kind of qualifier aware GC in D. pure function returns can be promoted to various heaps, so you need to segregate them somehow.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-24 7:51 GMT+01:00 Andrei Alexandrescu <span dir="ltr"><<a href="mailto:andrei@erdani.com" target="_blank">andrei@erdani.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Very nice idea, and realizable regardless of other work on lifetime management. Could you please submit it as a bugzilla issue?<br>
<br>
Thanks much, awesome idea!<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Andrei</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 12/23/2015 07:49 AM, Ralph Tandetzky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some pure functions use the garbage collector, but the allocated memory<br>
cannot escape the function due to its signature. Therefore all the<br>
created garbage could be locally collected at function exit.<br>
<br>
     int f( const int[] arr ) pure; // @localgc ?<br>
<br>
The only requirements on the function would be, that they are pure and<br>
that return types and argument types do not allow allocated memory to<br>
escape.<br>
<br>
And here's how I imagine it to work: At function entry the GC could be<br>
instructed to use a region allocator. At function exit the whole<br>
allocated memory is discarded all at once. The only problem I see with<br>
this, is that internally functions could be called which allocate memory<br>
in a tight loop producing to much garbage. Hence, collecting the garbage<br>
may be necessary in extreme cases. Therefore, the region allocator<br>
should not allow to much memory to be allocated, but fall back to<br>
garbage collection, if a lot of memory is requested. The good news is<br>
though, that this garbage collection can be local to our pure function.<br>
<br>
Therefore, it is not necessary to freeze the whole application or to<br>
scan the whole stack and global memory. Instead, only the running thread<br>
needs to scan the stack from our function upwards and the local pool of<br>
allocated memory and collect there.<br>
<br>
Pushing it all a little further: In templated code, where the all<br>
function definitions are visible to the compiler and no allocations are<br>
done in loops, heap allocations could be transformed into stack<br>
allocations by the compiler and the functions could even be marked<br>
@nogc. Standard library algorithms could use lambdas with captures like<br>
crazy again and do things idiomatically and functional in D while still<br>
ensuring @nogc.<br>
<br>
What do you think?<br>
_______________________________________________<br>
Dlang-study mailing list<br>
<a href="mailto:Dlang-study@puremagic.com" target="_blank">Dlang-study@puremagic.com</a><br>
<a href="http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study" rel="noreferrer" target="_blank">http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study</a><br>
</blockquote>
_______________________________________________<br>
Dlang-study mailing list<br>
<a href="mailto:Dlang-study@puremagic.com" target="_blank">Dlang-study@puremagic.com</a><br>
<a href="http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study" rel="noreferrer" target="_blank">http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study</a><br>
</div></div></blockquote></div><br></div>