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? That’s a pretty interesting idea. We actually load the JIT DLL before we execute any Python code so currently it wouldn’t have any issues with not having the full sized code objects created. But it could also let JITs store all of the info they need right there instead of having to create yet another place to track code data. And it fits in nicely with having the extra data being truly ephemeral that no one else should care about. It doesn’t help with the issue of potentially multiple consumers of that field that has been brought up before but I’m not sure how concerned we should be about that scenario anyway. I still want to check and see what the hash table overhead looks like but if that does end up looking bad I can definitely look at giving this a shot.
_______________________________________________ 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
