Idea #1 on integrating RC with GC

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Wednesday, 5 February 2014 at 16:01:09 UTC, Manu wrote:
> On 6 February 2014 01:32, <"Ola Fosheim Grøstad\"
> <ola.fosheim.grostad+dlang at gmail.com>"@puremagic.com> wrote:
> The applications I describe where it is a necessity will often 
> be 32bit
> systems.

You mean for embedded?

Mobile CPUs are going 64 bit…

> Cache locality is a problem that can easily be refined. It 
> would just need
> lots of experimental data.

Well, in that case the math is not so difficult. You could have 1 
index every 4MiB, and if your smallest allocation unit is 256 
bytes then you get a counter index of 16384 uint32 (64Kib)

The access would be easy and something like (probably not 100% 
correct):

counter_addr = (ptr&~0xffff) + ( (ptr>>12)&0xfffc )

>> Yes:
>>
>> struct {
>>     void* object_ptr;
>>     /* offset */
>>     uint weakcounter;
>>     uint strongcounter;
>> }
>>
>> The advantage is that it works well with RC ignorant
>> collectors/allocators. "if in doubt just set the pointer to 
>> null and forget
>> about freeing".
>
>
> I see. Well, I don't like it :) ... but it's an option.

The aesthetics isn't great, it is not a minimalist approach, but 
consider the versatility:

You could put in a function pointer to a deallocator (c-malloc, 
QT, GTK or some other library deallocator etc) and other kind of 
meta information that makes you able to treat reference counting 
in a uniform manner even for external resources.

With the right semantics you can have pointers to cached objects 
that suddenly disappear etc (by using weak counter in a clever 
way).