[Python-Dev] frame evaluation API PEP

[Christian Heimes]

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
>         co_extra field could be the very last field of the PyCodeObject
>         struct and only present if a certain flag is set in co_flags.
>         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 co_extra
> 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 co_extra. 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