We already have IDs for GC things that are stable across moving GCs, but I'm not 100% sure they are exposed in JSAPI.
Aha, looks like it is exposed: http://searchfox.org/mozilla-central/rev/594937fec2e2fc45fa9308ba2fb964816631f017/js/public/RootingAPI.h#660 On Mon, Dec 12, 2016 at 9:10 PM, Jim Blandy <jbla...@mozilla.com> wrote: > Honestly, I've never liked the devtools server's practice of using weakmaps > for every little thing. They're expensive, and the Debugger itself is > already using weakmaps internally for the association from real debuggee > things to their Debugger shadows, and guarantees distinct shadows for each > (debuggee thing, Debugger) pair, explicitly to help things work this way. > > So I'm in favor of putting the ids directly on the Debugger.Foo instances. > Death to weakmaps! > > > On Mon, Nov 21, 2016 at 1:24 AM, Eddy Bruel <ejpbr...@mozilla.com> wrote: > > > For the Servo debugger, we need some kind of IPC layer: > > > > The debugger server (i.e. the thing that talks the Chrome debugging > > protocol) needs to live in the same process (and perhaps even the same > > thread) as the constellation; it needs to work closely with the > > constellation to figure out which script threads exists, and to route > > messages to individual script threads. > > > > At the other end, the debugger API (i.e. the thing we use to examine the > > execution state of the JS engine) needs to live in the same thread as the > > one it is debugging (i.e. the script thread). In multiprocess mode, there > > will be a process boundary between the constellation and the script > > threads. Consequently, we need an IPC layer between the debugger server > and > > the debugger API in each script thread. > > > > Since the debugger API consists of a set of shadow objects (each of which > > represents som part of the execution state, such as stack frames, > > environments, scripts, etc), the obvious way to implement such an IPC > layer > > is as a set of proxies to each shadow object: to serialize a shadow > object > > over ipc, we assign it a unique ID. In the other direction, any message > > addressed to that id will be routed to the appropriate object. > > > > To route messages addressed to a specific id to the corresponding object, > > we need to maintain some for of id -> object map. Moreover, because the > > same shadow object can be obtained via different API calls, we need an > > object -> id map; this allows us to ensure that we never create more than > > one proxy for the same shadow object. > > > > Creating an object -> id map is problematic; since a *mut JSObject does > not > > have a stable address, it cannot be used as a key in a HashMap. The > obvious > > answer here is to use a WeakMap. WeakMaps are available in JSAPI, but as > > far as I can tell, not usable with the Rust bindings for JSAPI. > > > > Adding WeakMap support to the Rust bindings for JSAPI is probably > > non-trivial, so I'm looking for some kind of temporary workaround. The > > simplest option is perhaps to store the id directly on the JSObject. The > > Debugger API is designed so that defining arbitrary properties on shadow > > objects is well-defined. Since we control how these JSObjects are used > > (i.e. they are not exposed to arbitrary client JS), this should not lead > to > > conflicts. > > > > Another option is to create a WeakMap indirectly, by doing the equivalent > > of evaluating "new WeakMap()", storing the resulting JSObject, and then > > providing some strongly typed Rust API on top of it. Note that this is > very > > similar to what we do for the shadow objects in the debugger API. > > > > I am currently leaning towards the first option, but perhaps someone has > a > > better idea? > > _______________________________________________ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
