> So to the extent that b2g is in a "not enough hands" situation, implementing > in JS > makes sense.
I don't feel like b2g is in this position. We don't have a lot of Gecko hackers with 2+ years of experience, but we do have a lot of hackers. Whether or not we have a lot of C++ versus JS hackers, I can't say. > To the extent that we have code whose performance we want to maximize or whose > memory footprint we need to minimize, a JS implementation right now is not a > good > idea. My contention is that /everything that runs on B2G/ is code whose memory footprint we need to minimize. Fitting inside 120mb leaves very little room for waste. But it doesn't sound like you disagree too much with the idea of re-implementing the worst offenders in C++, as opposed to sitting back and hoping for heroics from the JS team. (To be clear, if I had to choose a team to deliver heroics, I'd choose the JS team in a heartbeat.) It seems foolhardy to me to on the one hand do the work of re-implementing these workers in C++, and on the other hand continue implementing DOM features in JS that eat up tens or hundreds of KB of memory each. But I suppose that's better than doing nothing, and if we all can agree on doing that much, I'd be happy. On Mon, Apr 22, 2013 at 10:40 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 4/21/13 7:51 PM, Justin Lebar wrote: >> >> Since most of these features implemented in JS seem to be DOM features, >> I'm >> particularly interested in the opinions of the DOM folks. > > > Opinions differ. ;) > > I think for DOM features that are not invoked on most pages, implementing > them in JS seems like a reasonable choice. We are actively working on > making this easier to do than it is now. > > This is only a viable implementation strategy for objects you don't expect > to have lots of around, since there is a lot more per-object overhead for a > JS-implemented DOM object. But lots of things that are currently > implemented in JS are per-page singletons, so that's ok. > > I'm very sympathetic to Andreas' points about memory-safety (especially for > hard-to-fuzz things) and ease of prototyping and implementation. But on the > flip side, there are security bugs that JS implementations are subject to > (involving content passing in unexpected objects and whatnot) that a C++ > implementation simply never has to deal with. See > https://bugzilla.mozilla.org/show_bug.cgi?id=856042 for those with the > access... I'm hoping that putting a WebIDL layer in front of the JS > implementations will help, but will of course add to the per-object > overhead. > > One other thing to keep in mind is that doing an implementation in JS does > not involve having to figure out cycle collection, etc, boilerplate... > > So to the extent that b2g is in a "not enough hands" situation, implementing > in JS makes sense. > > To the extent that we have code whose performance we want to maximize or > whose memory footprint we need to minimize, a JS implementation right now is > not a good idea. > > I'm afraid in practice the right decision should probably be made on a > per-component basis, and the hard part with that is making sure informed > decisions are made. :( > > -Boris > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
