----- Original Message ----- > The shell is already adapted for a moving GC, it's worked in the past > and the only problem is it keeps breaking because there is still no > tbpl coverage to catch such breakage. That doesn't mean zero bugs, > just that it passes with our current tests. Once tests are passing > and tbpl coverage is in, the rooting analysis will be ready for use > by fuzzers to look for further issues. I think that will settle > down quickly, if it doesn't there are several options to make things > more static, at the limit using sixgill for all paths coverage / > sound analysis.
How likely is that path to completion easier than doing it the dumb way? > There was a lot of navel gazing in the meeting about how this will > play in the browser. There's no good reason it won't be very > simple: > > 1. Replace bare GC thing pointers with handles in function arguments. > 2. Replace bare GC thing variables with rooted variables. Sounds simple enough, but I think you also need to take care that handles don't outlive roots, right? And how do you know you've caught everything? > This doesn't address everything, but it addresses everything which > your proposal would fix. Your proposal is fine from the perspective > of a code base that doesn't have rooting, but I don't see why it > would be any simpler than what we've already done. I'm concerned about: - How long it takes to finish. The current rooters/handles approach seems to carry risks of chasing huge numbers of fuzz bugs or of needing a static analysis to be built. - Stability of the final results. The dumb way seems to close off more bugs more easily. With the current approach, I'm worried that we might have uncaught bugs for a long time, like with compartments. - Usability of the API. I'm still unconvinced that's it's going to be nice for JSAPI users, and even somewhat for the internals. And then there's binary-component add-on authors. - Ongoing maintenance costs. If the API is harder to use, it will be more work to keep up. If we need to keep static or dynamic analyses around, that's more ongoing cost. > Brian Dave > ----- Original Message ----- > > From: "Dave Mandelin" <dmande...@mozilla.com> > > To: "mozilla dev tech js-engine internals" > > <mozilla.dev.tech.js-engine.intern...@googlegroups.com> > > Cc: sf...@mozilla.com, tc...@mozilla.com, bi...@mozilla.com, > > jo...@mozilla.com, "Brian Hackett" > > <bhack...@mozilla.com> > > Sent: Wednesday, June 27, 2012 7:16:53 PM > > Subject: Approach for adapting SpiderMonkey to moving GC > > > > I still have some concerns about our approach for adapting to > > moving > > GC. From the meeting notes, I see that there are some open concerns > > about maintaining proper handle usage outside the JS engine (and > > I'm > > not sure how easy it's going to be inside the engine for that > > matter) and more worrying even, about knowing if we've actually > > gotten it right, given all the cold paths. > > > > Today I was also thinking about compartments, which is a much > > simpler > > API, but where we are still chasing out compartment bugs, and where > > JSAPI users are still often doing it wrong. > > > > The last consideration is that I always like doing things the "dumb > > way" if possible, and I still don't think I've gotten an answer as > > to whether or not we can do this the dumb way. In my mind, the dumb > > way goes something like this: > > > > - Take the V8 handle API. We know how it works, and we know it's > > been > > used successfully. (Plus bonus points for aiming at API compat > > someday, but that's not a primary consideration for what I'm > > talking > > about now.) > > > > - Find the pinch points in the engine where we create objects, and > > make them create handles and return the handles instead. Steve > > pointed out to me that it's not quite as easy as that, because we > > need to cover places where we just read gcthing pointers out of the > > heap. Maybe we can set up all the heap pointers to be stored by > > classes that don't implicitly convert to a raw pointer to cover > > that > > part. > > > > - Fix all the compiler errors from the previous step by sticking > > handle types where needed. Inspect functions as this is done and > > add > > internal handle scopes as needed. > > > > - Add a few handle scopes to the shell. > > > > At this point we should have a JS shell that works with moving GC, > > no? It's possible this is all that's required. The biggest risk I > > see is that perf would be bad because of too many handles created > > internally where not needed. I'm not exactly sure how that would > > play out but I would imagine we'd try to find some simple patterns > > and refactor the code a bit to make it fairly clear and > > maintainable. > > > > Maybe I'm missing something, but it seems like this would work, > > that > > using the types and compiler checks would obviate most bugs, and it > > would be a large bulk of work but not require anything heroically > > complex. > > > > Would this work? > > > > Dave > > > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
