3 ms·
You're more exact, I tried to simplify. Whether they're CPU local depends on cache line state. It's fast in MESI protocol exclusive or modified state. Slow in
by vardump 10y ago
You're more exact, I tried to simplify.
Whether they're CPU local depends on cache line state. It's fast in MESI protocol exclusive or modified state. Slow in invalid and shared states.
However real systems have contended objects pretty much always.
I'm vaguely aware about differential reference counting, but don't know any systems that use it. A bit like fast multicore counters, that break one counter into multiple uncontended "sub-counters". Read operation adds all sub-counters together to get the "real" value.
> Re alloc and free, that's completely orthogonal with refcounting.
Technically true, but in real systems those go hand in hand almost always. Yeah, I have written firmware for embedded devices that do refcounting and don't allocate memory. But that's not the usual case.
- gpderetta 10y agoI guess that the reason that existing systems do not use advanced refcount modes is that they simply that either they are not meant for high performance (e.g. python, perl) or just don't do much refcount traffic (i.e. only long lived objects are refcounted and new references are not created often). Re alloc and free, I meant that you do not need to use the system malloc and free, you can be allocating and deallocating from a simple thread local bump allocator plus free list. At the limit you can have a fully generational GC behind and use the rerfcount only to decide when to run destructors or as an optimization.