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
