12-Apr-2013 18:12, Manu пишет:
On 13 April 2013 00:01, Regan Heath <re...@netmail.co.nz <mailto:re...@netmail.co.nz>> wrote:So... If the GC were to have a hook function for allocation and for free, and if when these were in use it would not itself trigger collection. Then... Manu could supply hook functions, use the alloc function to supply pre-allocated memory, and trigger collection as/when convenient. Believe it or not, I'm not actually a fan of over-complexity. And I'm focusing here on totally unnecessary allocations. Isn't using the stack where applicable just a whole low easier? That's what it's there for.
'cause nobody can tell you how big it is. This knowledge is only available to end user and there is still no easy way to "tell" that to the library. The end result is utterly useless as library can't reliably use stack space.
In the end if one library thinks it's fine to burn say 32K of stack with alloca but then it calls into another one that burns another chunk with alloca and so on untill happily stack overflowing (sometimes, on some systems at the right time!). Call graphs to calculate this is only available for the final app.
Maybe just adding a separate thread-local growable stack for data would work - at least it wouldn't depend on sheer luck and particular OS settings.
-- Dmitry Olshansky
