Idea #1 on integrating RC with GC

Michel Fortin michel.fortin at michelf.ca
Wed Feb 5 08:52:46 PST 2014


On 2014-02-05 15:52:36 +0000, Manu <turkeyman at gmail.com> said:

> On 6 February 2014 01:22, Michel Fortin <michel.fortin at michelf.ca> wrote:
> 
>> On 2014-02-05 15:01:04 +0000, Manu <turkeyman at gmail.com> said:
>> 
>> Since we're talking about adding reference counts to GC-allocated memory,
>> you could use the GC to find the base address of the memory block. What is
>> the cost of that?
> 
> Can you elaborate? How would the GC know this?

How do you think the GC tracks internal pointers today? ;-)

Just call addrOf if you need to know:

http://dlang.org/phobos/core_memory.html#.GC.addrOf

We'd have to call it too for incrementing/decrementing the reference 
count. It'd work, even though it seems rather heavyweight. The slow 
part of that function is the call to findPool, which does a binary 
search:

https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L1581

That 

said, the GC is already doing that for every word of memory it scans, 
so it might not be as heavyweight as it seems (especially if the GC has 
less to scan later because of ARC). See the mark function:

https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L2274

I'd 

tend to say that if you're in control of the reference count system, 
the code genereration, the allocation pools, as well as the GC 
algorithm you can probably do something that'll work well enough, by 
architecting things to work well together. But it requires an 
integrated approach.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca



More information about the Digitalmars-d mailing list