JSObject Makeover: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 1: Line 1:
Spun out from [https://bugzilla.mozilla.org/show_bug.cgi?id=408416].
== Possible JSObject changes ==
== Possible JSObject changes ==


* ops belongs on obj, not map
* ops belongs on obj, not map
* shape belongs on obj, not map, for cache-ready object types
* shape belongs on obj, not map, for cache-ready object types
** this makes a many-from-one update problem when regenerating shape
** alternative idea: share scope among all same-shaped objects in a thread
* obj should be something we can easily subclass, as we do with JSFunction
* obj should be something we can easily subclass, as we do with JSFunction
** this may require more size classes in the GC allocator


== Possible JSObjectOps changes ==
== Possible JSObjectOps changes ==
Line 12: Line 17:


Note that the current machinery avoids recursing on the C stack by iterating instead when the prototype _IS_NATIVE.  If we plan to wrap and stack freely, we'll want to avoid recursion in a less hackish way, e.g. by designing the ops to do tail calls or by making some ops refer only to "own" properties.
Note that the current machinery avoids recursing on the C stack by iterating instead when the prototype _IS_NATIVE.  If we plan to wrap and stack freely, we'll want to avoid recursion in a less hackish way, e.g. by designing the ops to do tail calls or by making some ops refer only to "own" properties.
(The lookup design has to be able to optimize across same-ops proto chains. This is the requirement that results in what may seem hackish but is (as you suggest) really tail call flattening into iteration. You can see where a non-native object along the chain causes js_LookupPropertyWithFlags to vector off into the foreign ops' lookupProperty hook. /be)


== Possible JSAPI changes ==
== Possible JSAPI changes ==


* Stop exposing JSObjectOps via jsapi.h.
* Stop exposing JSObjectOps via jsapi.h.
** Huzzah! let's do this now.


* Start phasing out JSClass from the API too.  Deprecate JSExtendedClass.  (Once we have ops for everything, I think we can mostly stop using JSClass internally too.  Depends on a few things.)
* Start phasing out JSClass from the API too.  Deprecate JSExtendedClass.  (Once we have ops for everything, I think we can mostly stop using JSClass internally too.  Depends on a few things.)
Line 26: Line 34:


* Kill resolve flags, of course.  Deprecate JS_LookupPropertyWithFlags.
* Kill resolve flags, of course.  Deprecate JS_LookupPropertyWithFlags.
** The DOM requires JSRESOLVE_ASSIGNING and JSRESOLVE_QUALIFIED or equivalents; don't reinvent as round a wheel!
Confirmed users, Bureaucrats and Sysops emeriti
419

edits