> On May 21, 2020, at 10:59, Richard Frith-Macdonald
> <rich...@frithmacdonald.me.uk> wrote:
>
>
>
>> On 21 May 2020, at 15:37, Larry Campbell <lcamp...@akamai.com> 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
