6 ms·

[disclaimer: I co-founded Mozilla Research, which sponsors Servo] It's awesome to see the Gecko team continue to tackle big, ambitious projects now that electr

• tomdale 10y ago
  I have to say, the work being done on Servo is really exciting—the first tectonic shift in browser engines to come along in years. pcwalton's talk about WebRender earlier this year[1] was one of those rare technical presentations that left my jaw on the floor. In particular, the insight that modern browsers are just AAA game engines with a security model, so they should be architected similarly, changed the way I think about browsers. That game developers and Mozilla are both so excited by Rust's ability to safely write parallel systems at scale makes a lot of sense. [1]: https://air.mozilla.org/bay-area-rust-meetup-february-2016/#@25m50s https://air.mozilla.org/bay-area-rust-meetup-february-2016/#... Previous HN discussion: https://news.ycombinator.com/item?id=11175258 https://news.ycombinator.com/item?id=11175258
• the8472 10y ago
  > The more we fully utilize those cores, the smoother we should be able to make the whole web. I wonder why the GC/CC are not multithreaded though. It seems like those are fairly isolated components, considering the entire application gets suspended so they can do their job, i.e. prime candidates for parallelism. When forcing a collection on a large firefox instance it can easily spend 20+ seconds collecting on a single thread while a java VM can munch churn through something like 1 gigabyte per second per core. In other words, from the outside it looks like a low-hanging fruit that has not been plucked.
  • johncolanduoni 10y ago
    That would be hard to do without writing a new javascript engine, which would expand Servo's current scope pretty dramatically. My guess would be that as long as there are big gains to be made that can be done without rewriting SpiderMonkey, the servo project would rather only tackle one massive project at a time :)
  • mccr8 10y ago
    Writing a parallel GC surely is not "low-hanging fruit" by any reasonable measure. Java already has to deal with concurrency in their objects, and throughput is more of a concern for server-like workloads, so they are dealing with a different situation. In Firefox, most of our effort has focused on improving responsiveness and eliminating work (through things like compartmental GC). (Some GC sweeping is already done in parallel in Firefox.) That said, I believe IE does some concurrent marking, so there is certainly room for improvement.
    • the8472 10y ago
      > and throughput is more of a concern for server-like workloads Many java applications also have to worry about latency, not just throughput. Parallel collections cut down on pause times, too. Simply because they can get about the same work (in terms of CPU cycles) done in less wall time. I.e. parallelizing non-concurrent GC phases also improves responsiveness.
  • pcwalton 10y ago
    > I wonder why the GC/CC are not multithreaded though. It seems like those are fairly isolated components, considering the entire application gets suspended so they can do their job, i.e. prime candidates for parallelism. > When forcing a collection on a large firefox instance it can easily spend 20+ seconds collecting on a single thread while a java VM can munch churn through something like 1 gigabyte per second per core. Several reasons why this isn't low-hanging fruit and isn't as valuable as it may seem: 1. Servo runs separate origins as fully separated JS VMs on separate threads. Because they're separate runtimes, the collections can already happen concurrently. 2. The isolated JS runtimes imply isolated heaps, so there is no need for global collection (and in fact no way to do it even if we wanted to with the current SpiderMonkey architecture). Small individual per-origin heaps are much faster to collect than large global heaps. 3. While collection is happening, like in other modern browsers, the Servo chrome and scrolling are fully responsive. But Servo goes beyond that: animations, layout, and repainting can also happen while a GC is occurring. This means that CSS transitions/animations on the page (all animations, not just transform and opacity!) will still happen while the page is collecting, and you can switch tabs and resize the window while the GC is running. You can even interact with cross-origin iframes on the page, so GCs triggered by ads won't affect the content you're reading! 4. SpiderMonkey already has incremental and generational GC, so we've done most of the work necessary to reduce stop-the-world pauses already. 5. Making a single-threaded GC concurrent is a lot of work. It's not low-hanging fruit by any stretch of the imagination. 6. Furthermore, making a single-threaded GC concurrent usually involves a throughput loss, because now you need operations to be atomic that weren't atomic before. That said, the GC is something that the SpiderMonkey team continues to make steady progress on, and that work directly benefits Servo. So fear not, we aren't neglecting the GC either :)
• armitron 10y ago
  It's telling that not one comment in this entire thread mentions security and exploitability, two areas where Firefox is not just terrible, but the worst choice amongst (Chrome, Safari, Firefox) (1) but also Edge and IE 11. Everyone is focusing on performance, as if that's the BIG issue these days. Talk about having your priorities screwed up. Reading your comment, and the linked post, I'm left with the impression that this will not change in the foreseeable future. Every exploit shop considers Spidermonkey a security clusterfuck yet it's still in use. Multiple processes do absolutely nothing for security unless combined with sandboxing ala-Chrome. Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security. Iteratively improving things on top of a Javascript engine that's a security disaster and a C++ core will not give us a secure browser, as one can not build castles on top of sand. At some point people need to realize that one has to scrap the pile of mud and start again, on solid foundations. Alas I feel that these lessons escape the Mozilla folks and thus their browser will remain low hanging fruit for adversaries. In an age where Nation States can MITM __the entire planet on demand__ [QUANTUM] and the FBI delivers Firefox 0day through TOR exit nodes, this blatant disregard for security should be entirely unacceptable. I don't really blame Mozilla, but those who use Firefox and give Mozilla their share in the browser market. If we don't demand better, we shall never have it. (1) http://cyber-itl.org/blog-1/2016/9/12/a-closer-look-at-the-osx-continuum http://cyber-itl.org/blog-1/2016/9/12/a-closer-look-at-the-o...
  • pcwalton 10y ago
    > Every exploit shop considers Spidermonkey to be a security clusterfuck yet it's still in use. Can you elaborate why SpiderMonkey is worse than Chakra, JavaScriptCore, and V8? SpiderMonkey has approximately the same security track record as all of them. I think you're conflating the lack of sandboxing and some mistaken security-related decisions in the Firefox chrome with some sort of intrinsic security problem in the JavaScript engine. > Multiple processes do absolutely nothing for security unless combined with sandboxing ala-Chrome. And sandboxing is being actively worked on right now. In fact, it's an utmost priority. Nobody is talking about doing Quantum instead of sandboxing. Rather, Quantum is being done alongside sandboxing. > Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security. I don't agree. Replacing C++ code with Rust code reduces the attack surface. The more of the browser you write in a memory safety language, the fewer opportunities for memory safety holes that attackers have. Do I want to shrink the trusted computing base as close to zero as possible? Absolutely! But that's a long-term journey, and I would love to see Servo components get some real-world production use along the way. > At some point people need to realize that one has to scrap the pile of mud and start again, on solid foundations. Alas I feel that these lessons escape the Mozilla folks and thus their browser will remain low hanging fruit for adversaries. There's only one browser vendor that is actively working on "scrapping the pile of mud and starting again", and it's the browser vendor you're complaining about. You claim that the lessons of security "escape" me, but I have been working day-in and day-out for years on a browser engine written from the ground up in a memory-safe language.
• xorcist 10y ago
  > all of Firefox's users have at least two cores, As an end user, it concerns me slightly that the visible change will be that Firefox pegs two cores instead of just one. An absolute explosion in Javascript usage on the web together, of low quality haphazardly put together at runtime, together with the convenience of tabs makes this a problem. Mozilla may do everything right but that doesn't necessarily help the end user. Is there anything I could do easily to remedy this, without bothering with white listing Javascript? And is there any activities at Mozilla concerning this, perhaps with identifying the most trivial cases of scripts spinning without doing useful work? Maybe pausing DOM changes for documents that aren't visible?
  • mdahlstrand 10y ago
    Disable javascript? Not that it's massively fun for you without javascript on the web, but it sounds like you have a very performance dependent workload on your computer. I don't think it's anything most people will have to worry about though, cpu scheduling is pretty good most of the time, and people's javascript suck less and less.
  • pcwalton 10y ago
    > Maybe pausing DOM changes for documents that aren't visible? We already throttle background tabs heavily in various ways.
• oldmanjay 10y ago
  I would personally not be so eager to disclaim such impressive credentials, but I suppose you have your reasons.