Re: 24-bit retain count

[David Chisnall]

On 21/05/2020 15:37, Larry Campbell wrote:
> Currently gnustep-base raises an exception if the retain count exceeds 24 bits. 
> There's a comment there:
>
>    /* I've seen comments saying that some platforms only support up to
>     * 24 bits in atomic locking, so raise an exception if we try to
>     * go beyond 0xfffffe.
>     */
>
> Is this really true? On what platforms? 24 bits is really not a very big 
> number. (It is causing me pain right now.)

The runtime currently uses a pointer-sized integer for the refcount, but 
steals the top bit as a flag to indicate whether the object has ever had 
weak references taken.  This means that the limit on 32-bit platforms is 
2^31 references.  When this saturates, we never decrement it, so the 
object leaks.  Given that you can't fit 2^31 4-byte pointers in a 32-bit 
address space, this won't affect any correct code.

On 64-bit platforms, iOS (and macOS?) embeds a small refcount in the isa 
pointer.  I'd quite like to do this at some point.  When this saturates, 
the object starts hitting slow paths because its refcount is now stored 
in a look-aside table.

For your particular use case, I have a few observations:

1. Don't do object pooling for small strings on 64-bit platforms. 
Strings that are 8 or fewer 7-bit characters are stored embedded in the 
pointer.  Copying these is cheaper than adding an indirection layer.  A 
*lot* of XML attribute names and values will fit in this size.

2. If you are doing interning you can avoid a lot of refcount 
manipulation by storing their ID in the pool, rather than the pointer. 
You can probably get away with 32-bit IDs, rather than 64-bit pointers. 
This will also reduce your memory consumption.

David