<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 20 Jun 2016 at 13:43 Christian Heimes <<a href="mailto:christian@python.org">christian@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016-06-20 22:18, Guido van Rossum wrote:<br>
> On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a><br>
> <mailto:<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>>> wrote:<br>
><br>
>         MRAB's response made me think of a possible approach: the<br>
>         co_extra field could be the very last field of the PyCodeObject<br>
>         struct and only present if a certain flag is set in co_flags.<br>
>         This is similar to a trick used by X11 (I know, it's long ago :-)<br>
><br>
><br>
>     But that doesn't resolve your memory worry, right? For a JIT you<br>
>     will have to access the memory regardless for execution count<br>
>     (unless Yury's patch to add caching goes in, in which case it will<br>
>     be provided by code objects already).<br>
><br>
><br>
> If you make the code object constructor another function pointer in the<br>
> interpreter struct, you could solve this quite well IMO. An interpreter<br>
> with a JIT installed would always create code objects with the co_extra<br>
> field. But interpreters without a JIT would have have code objects<br>
> without it. This would mean the people who aren't using a JIT at all<br>
> don't pay for co_extra. The flag would still be needed so the JIT can<br>
> tell when you pass it a code object that was created before the JIT was<br>
> installed (or belonging to a different interpreter).<br>
><br>
> Would that work? Or is it important to be able to import a lot of code<br>
> and then later import+install the JIT and have it benefit the code you<br>
> already imported?<br>
<br>
Ha, I had the same idea. co_flags has some free bits. You could store<br>
extra flags there.<br>
<br>
Is the PyCodeObject's layout part of Python's stable ABI?</blockquote><div><br></div><div>No: <a href="https://docs.python.org/3/c-api/code.html#c.PyCodeObject">https://docs.python.org/3/c-api/code.html#c.PyCodeObject</a></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I'm asking<br>
because the PyCodeObject struct has a suboptimal layout. It's wasting a<br>
couple of bytes because it mixes int and ptr. If we move the int<br>
co_firstlineno member below the co_flags member, then the struct size<br>
shrinks by 64 bits on 64bit system -- the exact same size a PyObject<br>
*co_extras member.<br></blockquote><div><br></div><div>:) We should probably do that reordering regardless of the result of this PEP. <br></div></div></div>