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