March 4, 2019
3:16 p.m.
On 2019-03-04, Neil Schemenauer wrote:
It seems one-to-one handles could use whatever solution the VM uses to implement id().
I forgot about hash() as well. We might not like id() but I don't think we can consider messing with hash(). I found this on the PyPy site:
https://pypy.readthedocs.io/en/release-2.4.x/garbage_collection.html
Minimark GC
...
The objects move once only, so we can use a trick to implement
id() and hash(). If the object is not in the nursery, it won’t
move any more, so its id() and hash() are the object’s address,
cast to an integer. If the object is in the nursery, and we ask
for its id() or its hash(), then we pre-reserve a location in
the old stage, and return the address of that location. If the
object survives the next minor collection, we move it there, and
so its id() and hash() are preserved. If the object dies then
the pre-reserved location becomes free garbage, to be collected
at the next major collection.It is a clever way to implement id() and hash(). However, if the API requires stable IDs for objects, it is as if you are calling id/hash on all of the objects passed over the extension API. I think that has the effect of copying all those objects out of the GC nursery. GC performance would be quite bad if you did it for a lot of objects.
Regards,
Neil