[Python-Dev] frame evaluation API PEP (original) (raw)

Christian Heimes christian at python.org
Mon Jun 20 16:41:40 EDT 2016

On 2016-06-20 22:18, Guido van Rossum wrote:

On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon <brett at python.org_ _<mailto:brett at python.org>> wrote:

MRAB's response made me think of a possible approach: the coextra field could be the very last field of the PyCodeObject struct and only present if a certain flag is set in coflags. This is similar to a trick used by X11 (I know, it's long ago :-)

But that doesn't resolve your memory worry, right? For a JIT you will have to access the memory regardless for execution count (unless Yury's patch to add caching goes in, in which case it will be provided by code objects already). If you make the code object constructor another function pointer in the interpreter struct, you could solve this quite well IMO. An interpreter with a JIT installed would always create code objects with the coextra field. But interpreters without a JIT would have have code objects without it. This would mean the people who aren't using a JIT at all don't pay for coextra. The flag would still be needed so the JIT can tell when you pass it a code object that was created before the JIT was installed (or belonging to a different interpreter). Would that work? Or is it important to be able to import a lot of code and then later import+install the JIT and have it benefit the code you already imported?

Ha, I had the same idea. co_flags has some free bits. You could store extra flags there.

Is the PyCodeObject's layout part of Python's stable ABI? I'm asking because the PyCodeObject struct has a suboptimal layout. It's wasting a couple of bytes becaues it mixes int and ptr. If we move the int co_firstlineno member below the co_flags member, then the struct size shrinks by 64 bits on 64bit system -- the exact same size a PyObject *co_extras member.

Christian

More information about the Python-Dev mailing list