Vote on region allocator

[dsimcha]

On 9/24/2011 3:08 AM, Andrei Alexandrescu wrote:
> On 9/24/11 1:19 CDT, Jonathan M Davis wrote:
>> On Saturday, September 24, 2011 01:10:44 Andrei Alexandrescu wrote:
>>> On 9/23/11 22:30 CDT, dsimcha wrote:
>>>> On 9/23/2011 11:25 PM, Robert Jacques wrote:
>>>>> On Fri, 23 Sep 2011 15:53:46 -0400, Jonathan M Davis
>>>>> <jmdavisProg at gmx.com> wrote:
>>>>>
>>>>> No. I cannot build an efficient and safe appender on this API.
>>>>
>>>> The resize() fix you requested is going to get implemented. I just
>>>> haven't actually added it yet.
>>>
>>> Then we might be hasty to vote this in. Ideally Phobos should be
>>> integrating tried and true APIs.
>>>
>>> I wish we voted allocator in once it's used throughout std.container to
>>> great effect.
>>
>> So, do you think that we should cease the vote then?
>
> At the risk of annoying David and others, allow me to vote against
> inclusion of the current proposal. There are three main reasons:
>
> 1. The proposal has been changed mid-review.

It was changed mid-review in response to some legitimate criticism.  I 
thought this is the way the review process is supposed to work.

>
> 2. There are hints of further changes post-review.

Agreed.

>
> 3. Only the scoped allocator has been used, but not the others.

Agreed, though to play Devil's Advocate this does create a 
chicken-and-egg problem.  If these allocators are buried somewhere in my 
Github page, probably noone except me and my GSoC mentees are going to 
use them.

>
> These threes are basis enough for a negative vote. That being said, this
> is excellent progress towards solving a very difficult problem.
>
> Below are some more thoughts about steps that could be taken to improve
> the design and its implementation.
>
> Fundamentally we want to make sure we cover the following allocators:

Agreed, eventually.  I just thought that this proposal would be enough 
to get the ball rolling and that this stuff would all be added later.

> Of these, the garbage-collected allocators need type information about
> the data, so we can only assume that any allocator needs it. There is
> some design in that direction, but it lacks the dynamic component.
> Generally the relationship between the structural/static interface and
> the dynamic interface is tenuous (when should one use one vs. the other?
> how does one pass type information about an allocation through the
> dynamic interface?)

Yeah, the dynamic interface was something proposed and added mid-review. 
  This was really my first shot at it.  You're right, it had not been 
reviewed or used at all.

>
> Currently the low-level interface traffics in void* (not even void[] or
> ubyte[] which may be better) and does not offer any way to e.g. set the
> type of a chunk after it's been allocated. This makes e.g. a precise
> garbage collector difficult to integrate (and impossible with the
> dynamic interface).

I stuck with void* because that's what core.memory uses.
>
> I think the interface should offer a bool freeAll() that frees all
> memory allocated by the given allocator. That would only work with
> scoped allocators and would return false for the others. Speaking of
> which, there's no property that says "free() is inoperant", which is the
> case for certain region-based allocators.

Good ideas.

>
> Finally, it would be great if some validation was available. There's no
> use of the dynamic interface with e.g. containers, which would have
> readily revealed e.g. the fact that a container can't pass type
> information to the allocator through the dynamic interface.

I guess using RTTI would be the solution here?

>
> We should also have some more examples of stacked allocators, e.g. that
> use free lists on top of regions etc. The current static design seems to
> be almost adequate. The way I see this all working is that allocators
> define the static interface for maximum performance and are stackable in
> infinite ways. Once the user decides on a stacking configuration, they
> simply wrap the entire stack in the dynamic interface and use that with
> e.g. a container.

I disagree slightly.  Again, getting these in Phobos eventually is a 
worthy goal, but I'd rather just get the ball rolling first.  I don't 
have time to write all these anytime soon, I haven't heard anyone else 
volunteer, and I think a single proposal with all of these would be 
overwhelming.