On Mon, 20 Jun 2016 at 13:43 Christian Heimes <christ...@python.org> wrote:
> On 2016-06-20 22:18, Guido van Rossum wrote: > > On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon <br...@python.org > > <mailto:br...@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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
