[Python-Dev] frame evaluation API PEP

[Brett Cannon]

On Mon, 20 Jun 2016 at 13:43 Christian Heimes <christian at python.org> wrote:

> 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?


No: https://docs.python.org/3/c-api/code.html#c.PyCodeObject


> I'm asking
> because the PyCodeObject struct has a suboptimal layout. It's wasting a
> couple of bytes because 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.
>

:) We should probably do that reordering regardless of the result of this
PEP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160620/08134eee/attachment.html>