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

[Manu]

On 13 April 2013 00:01, Regan Heath <regan at netmail.co.nz> wrote:

> 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.
>

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.

There are of course plenty of functions that do allocate by design, and in
many cases, allocators would assist with those. But I'm not arguing for
that right now, since allocators still seem to be a way off.

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

Absolutely. Is it possible for collection to run like a coroutine? Can it
run a fragmented collection process, each time picking up where it left off?

These ideas are nowhere near as complex as a full blown allocator
> proposal/idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130413/2ab016d5/attachment.html>