On Wednesday, 5 February 2014 at 16:01:09 UTC, Manu wrote:
On 6 February 2014 01:32, <"Ola Fosheim Grøstad\"
<[email protected]>"@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).
