Re: [rust-dev] Abandoning segmented stacks in Rust
Does ditching segmented stacks mean we can start getting a stack trace when a task `fail!`s? Or is this an unrelated issue? The lack of stack traces is extremely tedious when debugging failed assertions... ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
Entirely unrelated. Do note that we have stack traces *now*, as long as you're using gdb to get them :). Break on `rust_begin_unwind` or catch throw. On Fri, Nov 8, 2013 at 1:27 AM, Oren Ben-Kiki o...@ben-kiki.org wrote: Does ditching segmented stacks mean we can start getting a stack trace when a task `fail!`s? Or is this an unrelated issue? The lack of stack traces is extremely tedious when debugging failed assertions... ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
Good to know! The GDB stack traces leave something to be desired, though - e.g. the way it reports closures isn't really very useful (adding source file name and line number would be really good there). But it is certainly better than nothing. Thanks! On Fri, Nov 8, 2013 at 8:40 AM, Corey Richardson co...@octayn.net wrote: Entirely unrelated. Do note that we have stack traces *now*, as long as you're using gdb to get them :). Break on `rust_begin_unwind` or catch throw. On Fri, Nov 8, 2013 at 1:27 AM, Oren Ben-Kiki o...@ben-kiki.org wrote: Does ditching segmented stacks mean we can start getting a stack trace when a task `fail!`s? Or is this an unrelated issue? The lack of stack traces is extremely tedious when debugging failed assertions... ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
On Fri, Nov 8, 2013 at 1:45 AM, Oren Ben-Kiki o...@ben-kiki.org wrote: Good to know! The GDB stack traces leave something to be desired, though - e.g. the way it reports closures isn't really very useful (adding source file name and line number would be really good there). But it is certainly better than nothing. Thanks! Rust only has boxed (type erased) closures so there's no source data to associate with them. They're a function pointer and some data to go along with it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
How bad would it be to add another 64 bits to the some data to go along with it part? I'm assuming 32 bit for file name index in some table and 32 bit for the line number in the file should be enough :-) On Fri, Nov 8, 2013 at 8:48 AM, Daniel Micay danielmi...@gmail.com wrote: On Fri, Nov 8, 2013 at 1:45 AM, Oren Ben-Kiki o...@ben-kiki.org wrote: Good to know! The GDB stack traces leave something to be desired, though - e.g. the way it reports closures isn't really very useful (adding source file name and line number would be really good there). But it is certainly better than nothing. Thanks! Rust only has boxed (type erased) closures so there's no source data to associate with them. They're a function pointer and some data to go along with it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
On Fri, Nov 8, 2013 at 1:52 AM, Oren Ben-Kiki o...@ben-kiki.org wrote: How bad would it be to add another 64 bits to the some data to go along with it part? I'm assuming 32 bit for file name index in some table and 32 bit for the line number in the file should be enough :-) In debug builds, no problem at all. It would mean updating all code doing transmutes of closures and the code generation for them though. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
On Fri, Nov 8, 2013 at 1:59 AM, Daniel Micay danielmi...@gmail.com wrote: On Fri, Nov 8, 2013 at 1:52 AM, Oren Ben-Kiki o...@ben-kiki.org wrote: How bad would it be to add another 64 bits to the some data to go along with it part? I'm assuming 32 bit for file name index in some table and 32 bit for the line number in the file should be enough :-) In debug builds, no problem at all. It would mean updating all code doing transmutes of closures and the code generation for them though. On second thought... it does seem like if the debug data can be associated with functions, it's available for function pointers to them. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
Added https://github.com/mozilla/rust/issues/10350 then :-) On Fri, Nov 8, 2013 at 9:00 AM, Daniel Micay danielmi...@gmail.com wrote: On Fri, Nov 8, 2013 at 1:59 AM, Daniel Micay danielmi...@gmail.comwrote: On Fri, Nov 8, 2013 at 1:52 AM, Oren Ben-Kiki o...@ben-kiki.org wrote: How bad would it be to add another 64 bits to the some data to go along with it part? I'm assuming 32 bit for file name index in some table and 32 bit for the line number in the file should be enough :-) In debug builds, no problem at all. It would mean updating all code doing transmutes of closures and the code generation for them though. On second thought... it does seem like if the debug data can be associated with functions, it's available for function pointers to them. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
If you really need such a small memory footprint for your tasks, I am of the opinion that it would be less error prone (whoops, accidentally used 64 bytes of stack than I should have, now I'm using twice as much memory!) to use an async event loop, like libevent, rather than a task model. It just doesn't seem like it's as worthwhile - if you really need to have that faux synchronous IO, you could use FRP. I'm sure a lot of people would disagree with me, given the general direction rust has been going with tasks (IO, task-local errors, etc.) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
Segmented stacks aren't the only solution though. If the concern is many tasks that block for a long time, I imagine a mechanism to bundle a bunch of small, dormant stacks into a single page so that the original pages could be released to the OS. If stacks were additionally relocatable (which requires similar machinery as precise moving GC, if I'm not mistaken) then the released pages could be re-used for other tasks or heaps, which would be especially helpful on 32-bit. To address the problem of running out of address space on 32-bit, small-stack tasks could request a single-page stack (plus a guard page), which is enlarged by relocation as needed. Combining these techniques, you might be able to have up to a million small tasks in a 32-bit process. From: Bill Myers bill_my...@outlook.com The advantage of segmented stacks is that blocked tasks only take up as much memory as they actually need to store state, so that for instance a network server can use a task for each connection, and still only use, say, 64 bytes per connection if that's possible instead of the number of stack pages that got allocated for previous computation (assuming an extreme version that allocates a stack segment on every call). However, there is another approach that can replace segmented stacks for that purpose, namely having the compiler automatically transform blocking functions to instead return a future (with limited lifetime). This means that segmented allocation only happens for functions that indirectly perform I/O and only allocates the exact amount of memory needed to retain state that must persistent across the blocking I/O operation, while other functions execute normally using traditional stacks. The simplest example of this feature is async/await in C# 5, and Scala has a delimited continuation passing transformation that can be used to do the same thing. Has this been considered for Rust? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
On 11/5/13 8:32 AM, David Piepgrass wrote: Segmented stacks aren't the only solution though. If the concern is many tasks that block for a long time, I imagine a mechanism to bundle a bunch of small, dormant stacks into a single page so that the original pages could be released to the OS. If stacks were additionally relocatable (which requires similar machinery as precise moving GC, if I'm not mistaken) This is correct. It's conceivable (although I can't make any promises) that if and when LLVM supports this, we could experiment with doing what Go does. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
On 11/04/2013 07:50 PM, Bill Myers wrote: The advantage of segmented stacks is that blocked tasks only take up as much memory as they actually need to store state, so that for instance a network server can use a task for each connection, and still only use, say, 64 bytes per connection if that's possible instead of the number of stack pages that got allocated for previous computation (assuming an extreme version that allocates a stack segment on every call). In practice there are a number of other limitations that would ever prevent Rust from reducing a stack segment to 64 bytes. Rust segmented stacks still needed a large 'red zone' for running various bits of code, the most problematic being the dynamic linker. On Linux the dynamic linker needs about 2k of space to resolve symbols, on Mac much more. There are ways to work around this by writing our own dynamic linker or disallowing it, but there are significant obstacles to making the stack as small as one might want. We had the Linux minimum stack down to ~3k (1k for Rust code + *2k* red zone). With mmapped stacks we are always free to unmap pages that aren't in use, saving space. However, there is another approach that can replace segmented stacks for that purpose, namely having the compiler automatically transform blocking functions to instead return a future (with limited lifetime). This means that segmented allocation only happens for functions that indirectly perform I/O and only allocates the exact amount of memory needed to retain state that must persistent across the blocking I/O operation, while other functions execute normally using traditional stacks. The simplest example of this feature is async/await in C# 5, and Scala has a delimited continuation passing transformation that can be used to do the same thing. Has this been considered for Rust? Aren't these futures fullfilled by some kind of task abstraction that runs on a thread pool or something? Do these tasks not have their own stacks? I have thought about C#'s async/await feature but decided it was more or less equivalent to tasks. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
C# Async/Await is distinct from segmented stacks because they store the enclosed variables as heap objects rather than on the stack; that means it goes through the same malloc/garbage collector as any other heap objects you create. It's purely a compiler fiction to let you write code that 'looks' like it's stack allocating variables. On Tue, Nov 5, 2013 at 1:42 PM, Brian Anderson bander...@mozilla.comwrote: On 11/04/2013 09:21 PM, Oren Ben-Kiki wrote: Note that as memory becomes cheaper and larger there will be more pressure on 64-bit OS-es to switch to large pages; the number of pages needed to map several GBs of memory today is already getting out of hand, causing TLB misses to become a performance issue in some cases - imagine a system with 0.xTBs of memory and it becomes ludicrous. So playing tricks with MMU and lazy page loading may not work as well as it does with today's the small 4K page size. Of course, Rust is hardly the only platform that would be affected :-) and ideally, it would be possible to have more flexibility than today in choosing which page sizes are used where in the program's address space... but it remains to be seen how exactly this would play out. Just a point to keep in mind... Thanks! That is an interesting point that I hadn't thought about. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
On Tue, Nov 5, 2013 at 4:40 PM, Brian Anderson bander...@mozilla.com wrote: On 11/04/2013 07:50 PM, Bill Myers wrote: The advantage of segmented stacks is that blocked tasks only take up as much memory as they actually need to store state, so that for instance a network server can use a task for each connection, and still only use, say, 64 bytes per connection if that's possible instead of the number of stack pages that got allocated for previous computation (assuming an extreme version that allocates a stack segment on every call). In practice there are a number of other limitations that would ever prevent Rust from reducing a stack segment to 64 bytes. Rust segmented stacks still needed a large 'red zone' for running various bits of code, the most problematic being the dynamic linker. Plus the sysv amd64 ABI requires a 128 byte red zone under the stack anyway. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
Bill, memory is cheap. On Mon, Nov 4, 2013 at 9:50 PM, Bill Myers bill_my...@outlook.com wrote: The advantage of segmented stacks is that blocked tasks only take up as much memory as they actually need to store state, so that for instance a network server can use a task for each connection, and still only use, say, 64 bytes per connection if that's possible instead of the number of stack pages that got allocated for previous computation (assuming an extreme version that allocates a stack segment on every call). However, there is another approach that can replace segmented stacks for that purpose, namely having the compiler automatically transform blocking functions to instead return a future (with limited lifetime). This means that segmented allocation only happens for functions that indirectly perform I/O and only allocates the exact amount of memory needed to retain state that must persistent across the blocking I/O operation, while other functions execute normally using traditional stacks. The simplest example of this feature is async/await in C# 5, and Scala has a delimited continuation passing transformation that can be used to do the same thing. Has this been considered for Rust? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
Note that as memory becomes cheaper and larger there will be more pressure on 64-bit OS-es to switch to large pages; the number of pages needed to map several GBs of memory today is already getting out of hand, causing TLB misses to become a performance issue in some cases - imagine a system with 0.xTBs of memory and it becomes ludicrous. So playing tricks with MMU and lazy page loading may not work as well as it does with today's the small 4K page size. Of course, Rust is hardly the only platform that would be affected :-) and ideally, it would be possible to have more flexibility than today in choosing which page sizes are used where in the program's address space... but it remains to be seen how exactly this would play out. Just a point to keep in mind... On Tue, Nov 5, 2013 at 4:21 AM, Brian Anderson bander...@mozilla.comwrote: Instead of segmented stacks we're going to rely on the OS and MMU to help us map pages lazily. Although the details aren't clear yet, I expect that on 64-bit platforms the number of concurrent tasks will be comparable to using segmented stacks. On 32-bit platforms, with their limited address space, the situation will not be as good, but this is a calculated risk that we can live without the same amount of concurrency there. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Abandoning segmented stacks in Rust
Having memory is cheap, accessing it isn't.
On Monday, November 4, 2013, Thad Guidry wrote:
Bill, memory is cheap.
On Mon, Nov 4, 2013 at 9:50 PM, Bill Myers
bill_my...@outlook.comjavascript:_e({}, 'cvml', 'bill_my...@outlook.com');
wrote:
The advantage of segmented stacks is that blocked tasks only take up as
much memory as they actually need to store state, so that for instance a
network server can use a task for each connection, and still only use, say,
64 bytes per connection if that's possible instead of the number of stack
pages that got allocated for previous computation (assuming an extreme
version that allocates a stack segment on every call).
However, there is another approach that can replace segmented stacks for
that purpose, namely having the compiler automatically transform blocking
functions to instead return a future (with limited lifetime).
This means that segmented allocation only happens for functions that
indirectly perform I/O and only allocates the exact amount of memory needed
to retain state that must persistent across the blocking I/O operation,
while other functions execute normally using traditional stacks.
The simplest example of this feature is async/await in C# 5, and Scala
has a delimited continuation passing transformation that can be used to do
the same thing.
Has this been considered for Rust?
___
Rust-dev mailing list
Rust-dev@mozilla.org javascript:_e({}, 'cvml', 'Rust-dev@mozilla.org');
https://mail.mozilla.org/listinfo/rust-dev
--
-Thad
+ThadGuidry https://www.google.com/+ThadGuidry
Thad on LinkedIn http://www.linkedin.com/in/thadguidry/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
