Thread local and memory allocation

[Robert Jacques]

On Mon, 03 Oct 2011 15:48:57 -0400, deadalnix <deadalnix at gmail.com> wrote:

[snip]

> What I suggest in add a flag SHARED in BlkAttr and store it as an
> attribute of the block. Later modification could be made according to
> this flag. This attribute shouldn't be modifiable later on.
>
> What do you think ? Is it something it worth working on ? If it is, how
> can I help ?

I've been a proponent of thread-local garbage collection, so naturally I think it's a good idea :)

There are some GCs specifically tailored for immutable data, so I'd probably wish to add separate SHARED and IMMUTABLE flags.

On the con side, the major issue with thread-local GCs is that currently we don't have good ways of building shared and immutable data. This leads to people building data with mutable structures and casting at the end. Now the issue with shared, is mostly a quality of implementation issue. However, building immutable data structures efficiently requires a unique (aka. mobile) storage type, which we'll probably get at the same time D gets an ownership type system. That is to say, no time in the foreseeable future. That said, there are are mitigating factors. First, by far the most common example of the build & cast pattern involves string/array building; a task appender addresses in spades. Second, std.allocators could be used to determine which heap to allocate from. Third, we could op to be able to switch the GC from thread-local to shared mode and visa versa; the idea being that inside an object building routine, all allocations would be casted to immutable/shared and thus the  
local heap should be bypassed.

As for how can you help, I'd suggest building a thread local gc, following the design of the recent discussion on std.allocators, if you're up to it.