On Sat, 2 Mar 2019 at 04:11, Neil Schemenauer <nas-python@arctrix.com> wrote:
So, what's your opinion on that choice? Not requiring a one-to-one mapping for the handles makes things easier for the runtime but the API is harder to use correctly. Should we follow the JNI model or should we pay the cost to get one-to-one mapping?
If the runtime also pays the memory cost to keep a reference count in the handle table, I think I see how we could just make PyObject be the opaque handle.
Note that moving reference counts to a separate table is something we've previously discussed doing for CPython itself, with the two most notable problems being:
- the possible performance hit of the extra pointer dereference in Py_INCREF and Py_DECREF (et al)
- any third party code that's accessing ob_refcnt directly
The complete unknown from a performance persecptive is the potential CPU cache management impact of switching from scattered writes to a lot of different memory blocks to frequent writes to a particularly hot memory page (although we know up front that the centralised table will be far more copy-on-write friendly without any need for gc.freeze() shenanigans).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia