pike.git / multi-cpu.txt

version» Context lines:

pike.git/multi-cpu.txt:718:   not always true - code might change the stack further back to   reference new things, e.g. if a function allocates some temporary   struct on the stack and then pass the pointer to it to subroutines   that change it.      Such code on the C level is very unlikely, since it would mean that C   code would be changing something on the C stack back across a pike   level apply.      On the Pike level it can occur with inner functions changing variables - in their surrounding functions. Those cases can however be detected - and handle one way or the other. One way is to detect them at compile - time and "stay" in the frame of the outermost surrounding function for - the purposes of the micro-gc. That doesn't scale well if the inner - functions are deeply recursive, though. + in their surrounding functions. Those cases can however be handled by + following the pointer chain (pike_frame.scope) to those function + scopes, and that pointer chain is never deeper than the number of + lexically nested functions.      This micro-gc approach comes at a considerable expense compared to the   solution described in the issue "Garbage collector": Not only does the   generational gc with mark-and-sweep for young data disappear (which   according to the research paper gives 15-40% more total throughput),   but the delayed updating of the refcounts disappear to a large extent   too. Refcounting from the stacks is still avoided though, and delayed   updating of refcounts in shared data is still done, which is crucial   for multi-cpu performance.