On Mon, Nov 4, 2013 at 11:56 PM, Jonathan S. Shapiro <[email protected]>wrote:
> I really want to see that paper, because it really sounds like their > implementation was no good. Here are the things I need to know: > http://courses.cs.vt.edu/cs5204/fall05-gback/papers/capriccio-sosp-2003.pdf > > 1. What was their stack chunk size? > > "During this test, most functions could be executed entirely within the initial 4 KB chunk; when necessary, though, threads linked a 16 KB chunk in order to call a function that has an 8 KB buffer on its stack" > > 1. > 2. Why did they do the checkpoints this way? > > If you are willing to use a guard page, the checkpoint can be done in > *zero* marginal instructions. You have to zero the stack frame in any > case, so you simply make the first instruction of the procedure zero out > the deepest point of the call frame that you will need. If that puts you in > the guard page, you get a page fault and you deal with it. > "Our analysis achieves this goal without the use of guard pages, which would contribute unnecessary kernel crossings and virtual memory waste." Its not 100% convincing but they were running 100's of threads . If your going to go with a stack guard page you can just pause and expand the stack it should not be that often... Yes you can just attach a new segment but swapping in a whole new stack is also attractive as copies are pretty damn fast and you dont need to calculate segments and locality can be better ( though does require precise collection) . That is what Go is going with now though their previous implimentation had checks in every function ( as per the LLVM default).. In the case of the paper they were using C .. > It also sounds a bit like they weren't using stack chunks the right way. > The point of a stack chunk is to have a way to grow the stack if you need > to. It's not a tool for GC when used sensibly. > I didnt say or mean to imply it had anything to do with GC . 3-4% is a lot better than Rust/Go were getting . Singularity which used a similar technique to this paper also records segmented stacks have some cost since they mention possible HW assistance. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
