syscall heap

[convolvatron]

create a heap in the thread structure whose lifetime is explicitly tied to the duration of a syscall in the kernel to catch closures and other working structures. should live on top of a page cache and return all pages on thread_wakeup.

[wjhun]

We could re-introduce the rolling heap. Since the backed heap provides size-aligned allocations, a larger parent allocation order could be used to accommodate larger allocation sizes, much like what is done for the objcache. Though still bounded by the chosen allocation size (they need to be consistent for a given heap object in order to find the header / footer), > pagesize allocations would be attainable.

Of course, it can be a lot simpler than that since we don't need dealloc; the heap and its pages will be freed upon thread_wakeup. So dealloc would just be leak. The only risk here would be if one syscall could result in a large degree of memory churn...? Seems unlikely.

Even a chained list of allocations off of the general (mcache) heap that are freed upon destroy would suffice here, too. Though I like the idea of keeping the allocations quarantined in their own pages instead of being mixed within kernel's general heap.

[mkhon]

@wjhun do you think this one should be closed (in favor of #661)?

[wjhun]

I'm not sure if this should be closed. It's not really a duplicate of #661, and this is quite a defensible want. I referred to there being some risk of a heap that's only used for the lifetime of the system call, but if that's the case then the use of any kind of transient heap should be thrown out the window because there will always be such a risk of use-after-free (or use after the lifetime of the heap). So I don't think I got that right, and having such a per-syscall-heap would indeed solve a whole bunch of memory leaks with transient allocations (plus allocations coming off of general that really should be transient).

So perhaps, given some of the leaks we're seeing, this one could be bumped up in priority.