A few thoughts on std.allocator

[Morbid.Obesity via Digitalmars-d]

On Monday, 11 May 2015 at 15:45:38 UTC, Andrei Alexandrescu wrote:
> On 5/10/15 5:58 AM, Timon Gehr wrote:
>> Keep in mind that currently, entire regions of memory can 
>> change from
>> mutable to immutable implicitly when returned from pure 
>> functions.
>> Furthermore, as Michel points out, the ways 'immutable' can be 
>> leveraged
>> is constrained by the fact that it implies 'shared'.
>
> After sleeping on this for a bit, it seems to me pure function 
> need to identify their allocations in some way to the caller. 
> The simplest way is to have them conservatively use the most 
> conservative heap. We get to refine these later.
>
> For now, here's a snapshot of flags that the allocation 
> primitives should know about:
>
> enum AllocOptions
> {
>   /// Allocate an array, not an individual object
>   array,
>   /// Allocate a string of characters
>   string,
>   /// Plan to let the GC take care of this object
>   noFree,
>   /// This object will be shared between threads
>   forSharing,
>   /// This object will be moved between threads
>   forThreadTransfer,
>   /// This object will be mutable after initialization
>   mutableTarget,
>   /// The caller is a pure function, so result may be immutable
>   fromPureFunction,
>   /// Object allocated has pointers
>   hasPointers,
>   /// Typical (default) options
>   typical = array | noFree | forSharing | mutableTarget | 
> hasPointers
> }
>
> Anything to add to this?
>

fixed or pinned?

This will allocate the memory ala malloc and ignore it from hence 
forward. Similar to noFree but more expansive.

It seems to me that you really need to break up the allocation 
options into both allocation and deallocation along with the AUTO 
option. The auto option allows the compiler to attempt to 
determine the best option(scan for ptr's, etc). It would be the 
default option.

Allocation options are basically simpler and could include 
allocation specific things such as:

Fast, Fixed, GC, Manual, Stack, Heap, etc....

The deallocation options would essentially be your options 
above(since they really are talking about what to do when an 
object is deallocated).

Similarly I believe the GC and other memory managers should be 
parametrized with some protocol between different managers for 
cross-management.

E.g., Multiple heaps for different object memory orientation. GC 
uses one heap, ARC uses another. If an object cross the 
boundary(ptr to an object in another heap) then the memory 
manager trying to free the object has to inform the other memory 
manager.

This partitioning of memory into more specialized zones will 
provide more optimized options for the programmer. At some point