Re: 24-bit retain count

[Larry Campbell]

> On May 21, 2020, at 10:59, Richard Frith-Macdonald <address@hidden> wrote:
> 
> 
> 
>> On 21 May 2020, at 15:37, Larry Campbell <address@hidden> 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.)
> 
> It's probably not true of modern systems (certainly seems unlikely for 64bit 
> systems).
> However, the code in NSObject.m was written to support a lot of old systems 
> ...
> 
> On the other hand, while 24bits is not huge (16 million) I think it's big 
> enough so that hitting that limit is more likely to be a timely warning about 
> a memory management error (the same object being retained repeatedly and 
> never released) than a limitation,  so making it a configurable limit rather 
> than removing it altogether probably make sense (it is of course trivial to 
> hack NSObject.m to remove it).

Well actually the use case is a shared object pool. When you're parsing a 
large(*) XML document, for example, that has millions of

    <element attr="1"/>

I don't want to have to store millions of copies of the string "1", so I put 
the strings in a pool and share them. So the string "1" gets a huge reference 
count (as does the string "element").

- lc

(*) by "large" I mean 1G and growing