Thread local and memory allocation

[Robert Jacques]

On Tue, 04 Oct 2011 17:50:03 -0400, deadalnix <deadalnix at gmail.com> wrote:
> Le 04/10/2011 08:02, Robert Jacques a écrit :
>> 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.
>
> The GC switch you suggest doesn't take into account all cases. you
> cannot get something work without shared GC. The thing is that shared
> data must be collected with a shared collection cycle.
>
> But most of data aren't.
>

Well, our current GC behaves as a shared GC.