Hello! Ye olde https://bugs.webkit.org/show_bug.cgi?id=21295 from 2008 has a hopeful note that CallFrame is the new ExecState. Is this still the general desire? I'm sure I'll remember after this thread, but I've been confusing these for a long time now. We should choose one name or the other. I'm happy to file a mega-patch if there is consensus as to what to do. Thoughts? Regards, Andy
Hi Andy. Currently, CallFrame is a typedef for ExecState, in Register.h:
typedef ExecState CallFrame;
Most core VM code uses CallFrame, while most library code uses ExecState. Between ExecState and CallFrame, I would slightly favor using CallFrame. Due to the typedef, this doesn't actually need to be a mega-patch. You can work a file at a time or any logical unit at a time. Geoff On Mar 5, 2012, at 9:32 AM, Andy Wingo wrote:
Hello!
Ye olde https://bugs.webkit.org/show_bug.cgi?id=21295 from 2008 has a hopeful note that CallFrame is the new ExecState. Is this still the general desire? I'm sure I'll remember after this thread, but I've been confusing these for a long time now.
We should choose one name or the other. I'm happy to file a mega-patch if there is consensus as to what to do. Thoughts?
Regards,
Andy _______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
As an aside, I think the correct answer here is probably, for the most part we should change all the methods that take an ExecState to take a global data/object. Many library functions take an ExecState in order to be able to perform object allocation, but really only require either a JSGlobalData (to be able to get to the heap) or a JSGlobalObject (to be able to get to the heap, and to this execution context's set of global prototype objects). Passing an ExecState (or CallFrame) may be a useful optimization in a few cases, where a hot function typically does not not to perform an executable allocation (e.g methods like jsLess in Operations.h - may need to throw an exception when resolving a rope, but typically are just working on numeric values). In many cases functions that are passed an execstate are always going to extract a global object or global data, and doing so at the call site rather than within the callee would potentially mean we can share this action, and better encapsulate the VM implementation. But none of this means we need to maintain two different names for this – we should be able to resolve down to one. Passing an ExecState is probably only really valuable if we expect to actually need to retrieve values from the JS stack (e.g. access host function arguments), or may need to call a JS function & need to know the stack position (though this should be available via the JSGlobalData, now). If these are the primary responsibilities, then I think CallFrame beats ExecState as a name. cheers, G. On Mar 5, 2012, at 12:28 PM, Geoffrey Garen wrote:
Hi Andy.
Currently, CallFrame is a typedef for ExecState, in Register.h:
typedef ExecState CallFrame;
Most core VM code uses CallFrame, while most library code uses ExecState.
Between ExecState and CallFrame, I would slightly favor using CallFrame.
Due to the typedef, this doesn't actually need to be a mega-patch. You can work a file at a time or any logical unit at a time.
Geoff
On Mar 5, 2012, at 9:32 AM, Andy Wingo wrote:
Hello!
Ye olde https://bugs.webkit.org/show_bug.cgi?id=21295 from 2008 has a hopeful note that CallFrame is the new ExecState. Is this still the general desire? I'm sure I'll remember after this thread, but I've been confusing these for a long time now.
We should choose one name or the other. I'm happy to file a mega-patch if there is consensus as to what to do. Thoughts?
Regards,
Andy _______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
On Mon, 2012-03-05 at 12:58 -0800, Gavin Barraclough wrote:
As an aside, I think the correct answer here is probably, for the most part we should change all the methods that take an ExecState to take a global data/object.
Good point.
I think CallFrame beats ExecState as a name.
Cool. And as Geoffrey notes:
On Mar 5, 2012, at 12:28 PM, Geoffrey Garen wrote:
Due to the typedef, this doesn't actually need to be a mega-patch.
Indeed. Thanks for the feedback! Andy
participants (3)
-
Andy Wingo
-
Gavin Barraclough
-
Geoffrey Garen