inlining scopechainnode into scope objects
Hi Gavin, hi list, As we discussed last week, it could be a good idea to inline ScopeChainNode into scope objects, effectively giving scope objects a pointer to the next object in the chain. "With" objects would be on the chain via a wrapper object. This way we remove an indirection on accessing scopes and an allocation when creating them. I'm giving it a go, as it make some block stuff easier. So far so good. The current class hierarchy looks like: JSScopeObject: A new base class, holding the next pointer, global object, and global this + JSDynamicScope: A new class, wrapping "with" objects in the scope. + JSVariableObject + JSStaticScopeObject + JSActivation + JSGlobalObject Anyway, now my question: what is the deal with the "globalThis" object? Specifically, does it exist in a 1-to-1 relationship with the global object? If so, then it's fine to have globalThis be a (possibly settable) field of JSGlobalObject. If not, I have to rethink this plan. In the meantime I'll continue pushing forward here. Regards, & comments welcome, Andy -- Igalia, S.L.
JSScopeObject: A new base class, holding the next pointer, global object, and global this
+ JSDynamicScope: A new class, wrapping "with" objects in the scope.
I'd prefer to be more specific: "JSWithScope".
+ JSVariableObject
Even though the spec uses the phrase "variable object", I think we should move to something clearer and more consistent with your other naming: "JSVarScope".
+ JSStaticScopeObject
I'd prefer to be more specific: "JSLetScope". There's one special case (catch blocks) where, logically, the engine implies the let statement for you. But I don't think that justifies an abstract name. In general, you can remove "Object" from the class names above. Every object is an object.
+ JSActivation
+ JSGlobalObject
Anyway, now my question: what is the deal with the "globalThis" object? Specifically, does it exist in a 1-to-1 relationship with the global object?
For any give JSGlobalObject, there is only one globalThis. Geoff
On Thu 26 Apr 2012 11:59, Andy Wingo <wingo@igalia.com> writes:
As we discussed last week, it could be a good idea to inline ScopeChainNode into scope objects, effectively giving scope objects a pointer to the next object in the chain.
"With" objects would be on the
chain via a wrapper object. This way we remove an indirection on accessing scopes and an allocation when creating them. I'm giving it a go, as it make some block stuff easier.
So far so good. The current class hierarchy looks like:
JSScopeObject: A new base class, holding the next pointer, global object, and global this
+ JSDynamicScope: A new class, wrapping "with" objects in the scope.
+ JSVariableObject
+ JSStaticScopeObject
+ JSActivation
+ JSGlobalObject
Anyway, now my question: what is the deal with the "globalThis" object? Specifically, does it exist in a 1-to-1 relationship with the global object? If so, then it's fine to have globalThis be a (possibly settable) field of JSGlobalObject. If not, I have to rethink this plan.
In the meantime I'll continue pushing forward here.
Regards, & comments welcome,
Andy
On Thu 26 Apr 2012 11:59, Andy Wingo <wingo@igalia.com> writes:
As we discussed last week, it could be a good idea to inline ScopeChainNode into scope objects, effectively giving scope objects a pointer to the next object in the chain.
Before I go too far down this thing, a note. This makes the scope chain link a part of JSScope, a derived JSObject. The scope chain is the part of the call frame that holds onto the JSGlobalObject and JSGlobalData, and the compiler needs to be able to inline exec->globalData() / exec->globalObject() in a whole pile of code, including JSObject.h itself. I am going to attempt to make JSObject.h not dereference the ExecState* data type. There are only a few cases in which it needs to do this, but changing those cases to accept a JSGlobalObject& ends up changing the prototype of JSObject::getOwnPropertySlot. I think I can manage this change, but it is a fair amount of work, and I wanted to get some feedback before getting too deep. Thoughts? Andy ps. This is unrelated to https://bugs.webkit.org/show_bug.cgi?id=85200. -- http://wingolog.org/
Our strategy for this kind of problem, rather than re-engineering code to work around inlining dependencies, is just to make a separate "{Class}Inlines.h", where the inline functions are defined, and require any .cpp file that calls those functions to #include "{Class}.h" and "{Class}Inlines.h". Geoff On Apr 30, 2012, at 9:54 AM, Andy Wingo wrote:
On Thu 26 Apr 2012 11:59, Andy Wingo <wingo@igalia.com> writes:
As we discussed last week, it could be a good idea to inline ScopeChainNode into scope objects, effectively giving scope objects a pointer to the next object in the chain.
Before I go too far down this thing, a note. This makes the scope chain link a part of JSScope, a derived JSObject. The scope chain is the part of the call frame that holds onto the JSGlobalObject and JSGlobalData, and the compiler needs to be able to inline exec->globalData() / exec->globalObject() in a whole pile of code, including JSObject.h itself.
I am going to attempt to make JSObject.h not dereference the ExecState* data type. There are only a few cases in which it needs to do this, but changing those cases to accept a JSGlobalObject& ends up changing the prototype of JSObject::getOwnPropertySlot. I think I can manage this change, but it is a fair amount of work, and I wanted to get some feedback before getting too deep.
Thoughts?
Andy
ps. This is unrelated to https://bugs.webkit.org/show_bug.cgi?id=85200. -- http://wingolog.org/ _______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
On Mon 30 Apr 2012 19:55, Geoffrey Garen <ggaren@apple.com> writes:
Our strategy for this kind of problem, rather than re-engineering code to work around inlining dependencies, is just to make a separate "{Class}Inlines.h", where the inline functions are defined, and require any .cpp file that calls those functions to #include "{Class}.h" and "{Class}Inlines.h".
Okeydoke, will do. Thanks for the note. Andy -- http://wingolog.org/
participants (2)
-
Andy Wingo
-
Geoffrey Garen