On 2015-03-01 01:40:42 +0000, Andrei Alexandrescu said:
Tracing garbage collection can afford the luxury of e.g. mutating data
that was immutable during its lifetime.
Reference counting needs to make minute mutations to data while
references to that data are created. In fact, it's not mutation of the
"useful" data, the payload of a data structure; it's mutation of
metadata, additional information about the data (i.e. a reference count
integral).
The RCOs described in DIP74 and also RCSlice discussed in this forum
need to work properly with const and immutable. Therefore, they need a
way to reliably define and access metadata for a data structure.
One possible solution is to add a "@mutable" or "@metadata" attribute
similar to C++'s keyword "mutable". Walter and I both dislike that
solution because it's hamfisted and leaves too much opportunity for
abuse - people can essentially create unbounded amounts of mutable
payload for an object claimed to be immutable. That makes it impossible
(or unsafe) to optimize code based on algebraic assumptions.
We have a few candidates for solutions, but wanted to open with a good
discussion first. So, how do you envision a way to define and access
mutable metadata for objects (including immutable ones)?
Store the metadata in a global hash table.
There's a problem with reference counting immutable objects: they are
implicitly shared. Any metadata attached to them thus needs to be
shared. Accessing the metadata through a global shared hash table isn't
going to be that much of a performance hit compared to whatever
mechanism is used to synchronize access to that data.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/