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

[Regan Heath]

On Fri, 12 Apr 2013 14:25:22 +0100, Dmitry Olshansky  
<dmitry.olsh at gmail.com> wrote:

> 12-Apr-2013 17:20, Dicebot пишет:
>> On Friday, 12 April 2013 at 13:09:19 UTC, Lars T. Kyllingstad wrote:
>>> On Friday, 12 April 2013 at 13:00:36 UTC, Robert wrote:
>>>> I would suggest, instead of writing your own std.process, that you
>>>> simply provide a pull request to the now to be approved one, this way
>>>> you can prove your point that it is easy by already improving a part  
>>>> of
>>>> the standard library.
>>>
>>> Actually, Manu (or anyone) could do this for *any* part of Phobos.
>>> And considering that std.process is probably the module that would
>>> benefit the least from it, maybe he should start somewhere else?
>>> std.string, perhaps, or std.algorithm?
>>
>> Or probably druntime. This rise again and again - until standard global
>> allocators are not here it is all a premature and useless optimization.
>> It makes no sense to try to workaround a fundamental issue. That will be
>> a lot of effort for no real gain.
>>
>> Allocators are a blocker for almost any memory-related issue in both
>> druntime and phobos.
>
> Same here - trying to get out of your way to avoid GC right now is both  
> painful and useless in the long run. More then that it's limited as you  
> can't have the default allocation scheme that fits all nor use some  
> scheme that would require change of API (so that later it's broken again  
> once allocators come).

My impression is that there is some low hanging fruit here.  My impression  
(pls correct me if I'm wrong) is that Manu is not trying to avoid the GC,  
but to avoid allocations (and presumably collections) at the wrong moment  
in time.

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.

For collection itself some upper bound time would also be desireable.

These ideas are nowhere near as complex as a full blown allocator  
proposal/idea.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/