On 11-08-13 12:52 PM, Patrick Walton wrote:
On 08/13/2011 12:47 PM, Marijn Haverbeke wrote:
Where bailing out means it simply allocates more memory and doesn't
collect anything? I can imaging a long-running computation inside some
generic function 'leaking' until it runs out of memory.
Yup, it can definitely leak. We need to solve this problem for real at
some point.
Does every generic have a dynamically sized frame or only those who
create locals
of parameterized variables?
Only the latter. We'd need to add an analysis pass that determines
whether the frame is dynamically-sized.
Two slightly more appealing (to me) solutions:
(1) The stack-growth work being done has, IIRC, a "parallel-stack"
stack for dynamic allocas, simply to address this sort of ugly;
likely we can make sure that we're using this for dynamic allocas
by the time we ship, so you don't have "dynamic frames" per se.
(2) Possibly just ban dynamic allocas. It's not clear to me that we
need them. Can't take dynamic args by value already; maybe dynamic
locals aren't needed either. In the limit you can always make a
local ~T, not as efficient but at least it won't leak.
For now I'd be happy to see a gc that can collect even the simplest
cyclic objects; it can give up on confusing frames if that keeps you moving.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
