[Python-Dev] gc ideas -- sparse memory

[Maciej Fijalkowski]

On Sat, Dec 4, 2010 at 1:37 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 4 Dec 2010 15:06:45 +1100
> Cameron Simpson <cs at zip.com.au> wrote:
>> On 03Dec2010 18:15, James Y Knight <foom at fuhm.net> wrote:
>> | On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote:
>> | > gc is implementation specific. CPython uses ref counting + cycle
>> | > gc. A constraint on all implementations is that objects have a fixed,
>> | > unique id during their lifetime. CPython uses the address as the id, so
>> | > it cannot move objects. Other implementations do differently. Compacting
>> | > gc requires an id to current address table or something.
>> |
>> | It's somewhat unfortuante that python has this constraint, instead of
>> | the looser: "objects have a fixed id during their lifetime", which is
>> | much easier to implement, and practically as useful.
>>
>> Python doesn't have the constraint you imagine; it _does_ have "objects
>> have a fixed id during their lifetime".
>>
>> _CPython_ has this constraint because it uses the address as the id,
>> which is free and needs no papping or extra storage.
>
> Well, the main reason CPython has this constraint is that the C API
> mandates constant object pointers. That we can then reuse the pointer
> for id() is only a consequence of this.
>
> Regards
>
> Antoine.
>

Yes.

I think further discussion of Java-vs-Python makes no sense (and it's
proven that C-API-less python can exist and be compatible)