On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon <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? -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160620/72f58426/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4