Allocatoin policy in Phobos - Was: Vote for std.process

[Dmitry Olshansky]

12-Apr-2013 18:12, Manu пишет:
> On 13 April 2013 00:01, Regan Heath <regan at netmail.co.nz
> <mailto:regan at 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