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.
