Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Firefox Mozilla Programming News

Firefox Javascript Engine Becomes Single Threaded 346

An anonymous reader writes with news about work on Mozilla's Javascript engine. Quoting Mozilla engineer Luke Wagner's blog: "With web workers in separate runtimes, there were no significant multi-threaded runtime uses remaining. Furthermore, to achieve single-threaded compartments, the platform features that allowed JS to easily ship a closure off to another thread had been removed since closures fundamentally carry with them a reference to their original enclosing scope. Even non-Mozilla SpiderMonkey embeddings had reportedly experienced problems that pushed them toward a similar shared-nothing design. Thus, there was little reason to maintain the non-trivial complexity caused by multi-threading support. There are a lot of things that 'would be nice' but what pushed us over the edge is that a single-threaded runtime allows us to hoist a lot data currently stored per-compartment into the runtime. This provides immediate memory savings."
This discussion has been archived. No new comments can be posted.

Firefox Javascript Engine Becomes Single Threaded

Comments Filter:
  • by Sez Zero ( 586611 ) on Wednesday January 25, 2012 @02:14PM (#38820309) Journal
    "memory savings".
    • by Anonymous Coward on Wednesday January 25, 2012 @02:27PM (#38820467)

      There's a reason they're the most efficient browser when it comes down to memory usage. They actively work at it.

      • Re:You had me at.. (Score:5, Informative)

        by jellomizer ( 103300 ) on Wednesday January 25, 2012 @02:56PM (#38820847)
        However memory usage is one of those moot points.
        Often (Not all the time) you come to a trade off of performance vs memory usage.
        Sometimes it is better to store a bunch of data in memory just for quick reference then having to calculate it over and over again or worse need to get it from slower storage such as a disk.
        Now there are things you can do to optimize the memory usage so it isn't as wasteful. However if you goal on low memory foot print chances are you are going to be sacrificing performance to use less memory.
    • Me too. At first I was like "Yay!", then I said to myself: "let's wait and see".

  • SetTimeout (Score:5, Interesting)

    by Anonymous Coward on Wednesday January 25, 2012 @02:15PM (#38820319)

    Maybe I'm missing something, but then how will "threading" (i use that term extremely loosely) methods like SetInterval and SetTimeout be implemented?

  • by ShakaUVM ( 157947 ) on Wednesday January 25, 2012 @02:21PM (#38820401) Homepage Journal

    "us to hoist a lot data currently stored"

    I really wish I knew what this phrase meant. It sounds fascinating.

    But seriously, if there's no performance gain from multithreading, it can be a really good idea to move away from the complexity of it. There's a lot of traps people can fall into with concurrent code if they don't know what they're doing.

    • by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Wednesday January 25, 2012 @03:06PM (#38820981) Homepage

      They mean to replace multiple per-thread copies of data with one single copy of it, accessible by all threads. No doubt part of Mozilla's latest push to reduce memory consumption.

      One feature of x86 is that, save for a specialized SSE streaming store instruction, any store made by one core is immediately visible to all the other cores—even when the old value was already in a core's cache.

      Maintaining such cache coherency involves a lot of overhead, so to get better scalability multi-threaded apps will sometimes adopt a "share-nothing" model: all threads get their own copy of the data, and no other threads will ever get to touch it. You trade memory and complexity for speed.

      It sounds like Mozilla has decided this trade off is no longer worth it, and so has done away with multi-threading all together. Perhaps they will use green threads [wikipedia.org] instead of native threads, though that brings along its own bag of complexities.

  • A mistake (Score:4, Informative)

    by claytongulick ( 725397 ) on Wednesday January 25, 2012 @02:58PM (#38820867) Homepage

    My initial sense of this, is that they are making a huge mistake here. I'll have to do more research, but my feeling is that they are moving in the wrong direction with this decision.

    One of the really cool "baked in" things with functional style language is their fundamental support for horizontal scaling across CPUs. My hope has been that javascript evolves towards this, so that the generic suite of functional methods become massively performant on a larger scale with map/reduce/fold/each calls.

    Closures present a bottleneck here, but it seems like a reasonable runtime could make some intelligent prediction about whether the isolated function is a closure or not, and ship it off to a different CPU/thread depending on optimization strategies, or even estimated closure size. Even better, this could be done at runtime with some runtime optimization based on execution metrics of an anonymous/declared function in-context.

    At the point of calling the map/reduce/fold/each function, the runtime should be able to decide whether to parallelize out the call, or even use some language extensions to let the developer specify the threading.

    The point is, now that they're making this decision, all of those options are gone from FF. And at a terrible time too. As we move toward CPU architectures that encourage parallelism, Mozilla is taking js off the table as a first-class language able to easily exploit those new architectures. That strikes me as a huge mistake, and I'm struggling to understand the rationale.

    • Re:A mistake (Score:4, Informative)

      by msclrhd ( 1211086 ) on Wednesday January 25, 2012 @05:34PM (#38822637)

      The old JavaScript runtime supported multi-threading in the runtime itself. This resulted in the need for complex threading/locking code to make sure that data was being accessed correctly. This is hard to maintain, easy to get wrong, consumes more memory and slows down things like garbage collection.

      The new JavaScript runtime is single-threaded. WebWorkers each have their own instance of a (single-threaded) JavaScript runtime that may be running on different threads.

      You can still have your map/reduce/fold/... functions running in parallel; they will be implemented on top of WebWorkers. As the representation of each runtime is simpler, the engine as a whole can optimise the work between threads better and perform better code generation.

      It also means that garbage collection is faster as it (a) does not navigate all memory allocated across all threads and (b) only blocks the thread the garbage collector is currently running on.

  • by bzipitidoo ( 647217 ) <bzipitidoo@yahoo.com> on Thursday January 26, 2012 @03:05AM (#38826053) Journal

    As an exercise in insanity, I tried to install a modern Linux distro on an old Pentium II system with only 128M of RAM. Used btrfs for the heck of it. It was all going well until I tried to run Firefox 9.0.1. Thrashed that system mercilessly. Never mind actually showing a web page, just starting up blank was extremely slow. Sometimes I saw the "unresponsive script" popups on Firefox's own Javascript. I hacked out everything that used memory, dumping the LXDE desktop environment for a plain old window manager (jwm), and this helped, but it's not enough. Turned off images and disabled Javascript. It still thrashes swap.

    Chrome didn't do any better. Firefox 3.5 worked okay on an even smaller system (96M of RAM). Version 3.6.8 + LXDE works fine on a system with 192M of RAM. Here's hoping their MemShrink effort scores more big wins.

"Let every man teach his son, teach his daughter, that labor is honorable." -- Robert G. Ingersoll