<div dir="ltr"><div dir="ltr"><div dir="ltr">On Tue, Feb 26, 2019 at 3:56 PM Neil Schemenauer <<a href="mailto:nas-python@arctrix.com">nas-python@arctrix.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Right.  I wonder though, could we avoid allocating the Python frame<br>
object until we actually need it?  Two situations when you need a<br>
heap allocated frame come to mind immediately: generators that are<br>
suspended and frames as part of a traceback.  I guess<br>
sys._getframe() is another.  Any more?<br>
<br></blockquote><div><br></div><div>I've been thinking about that as well...  I think in some ways the easy part of <br></div><div>this is actually the easy part of this is the reification of the frame it's self.  You <br></div><div>can have a PyFrameObject which is just declared on the stack and add a new <br></div><div>field to it which captures the address of the PyFrameObject* f (e.g. <br></div><div>PyFrameObject **f_stackaddr).  When you need to move to aheap allocated <br></div><div>one you copy everything over as you say and update *f_stackaddr to point <br></div><div>at the new heap address.</div><div><br></div><div>It seems a little bit annoying with the various levels of indirection from the <br></div><div>frame getting created in PyEval_EvalCodeEx and flowing down into <br></div><div>_PyEval_EvalFrameDefault - so there may need to be some breakage there for <br></div><div>certain low-level tools.  I'm also a little bit worried about things which go looking <br></div><div>at PyThreadState and might make nasty assumptions about the frames already <br></div><div>being heap allocated.</div><div><br></div><div>FYI IronPython does support sys._getframe(), you just need to run it with a <br></div><div>special flag (and there are various levels - e.g. -X:Frames and -X:FullFrames, <br></div><div>the latter which guarantees your locals are in the frame too).  IronPython is more <br></div><div>challenged here in that it always generates "safe" code from a CLR perspective <br></div><div>and tracking the address of stack-allocated frame objects is therefore <br></div><div>challenging (although maybe more possible now then before with various C# ref</div><div>improvements).  <br></div><div><br></div><div>I'm not sure exactly how much this approach would get though...  It seems like <br></div><div>the frame caches are pretty effective, and a lot of the cost of them is initializing <br></div><div>them / decref'ing the things which are still alive in them.  But it doesn't seem a <br></div><div>like a super complicated change to try out...  It's actually something I'd at least <br></div><div>like to try prototyping at some point.<br></div></div></div></div></div>