Le 04/10/2011 08:02, Robert Jacques a écrit :
On Mon, 03 Oct 2011 15:48:57 -0400, deadalnix <deadal...@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.
