Re: [Python-Dev] frame evaluation API PEP

2016年6月20日 13:45:07 -0700

On 2016年06月20日 22:18, Guido van Rossum wrote:
> On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon <[email protected]
> <mailto:[email protected]>> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to