Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Saturday June 20 2015, @01:43AM   Printer-friendly
from the still-trying dept.

Mozilla's Project Electrolysis aims to allow tabs and user interfaces to run in separate processes. It has been activated by default in recent nightly builds:

In current versions of desktop Firefox, the entire browser runs in a single operating system process. In particular, the JavaScript that runs the browser UI (also known as "chrome code") runs in the same process as the code in web pages (also known as "content" or "web content"). Future versions of Firefox will run the browser UI in a separate process from web content. In the first iteration of this architecture all browser tabs will run in the same process, and the browser UI will run in a different process. In future iterations, we expect to have more than one content process.

Developer Will Bamberg says the change will bring stability and security improvements. "There are three main reasons for making Firefox run content in a separate process: performance, security, and stability, Bamberg says. "The goal is to reduce 'jank' -- those times when the browser seems to briefly freeze when loading a big page, typing in a form, or scrolling. "In multiprocess Firefox, content processes will be sandboxed. A well-behaved content process won't access the filesystem directly; it will have to ask the main process to perform the request." Bamberg says "well-behaved" content processes needs to access much of the network and file systems. This would be much more restricted under the changes.

Former CEO of Mozilla Brendan Eich has announced a project called WebAssembly that could replace asm.js:

It's by now a cliché that JS has become the assembly language of the Web. Rather, JS is one syntax for a portable and safe machine language, let's say. Today I'm pleased to announce that cross-browser work has begun on WebAssembly, a new intermediate representation for safe code on the Web.

What: WebAssembly, "wasm" for short, .wasm filename suffix, a new binary syntax for low-level safe code, initially co-expressive with asm.js, but in the long run able to diverge from JS's semantics, in order to best serve as common object-level format for multiple source-level programming languages.

Who: A W3C Community Group, the WebAssembly CG, open to all. As you can see from the github logs, WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks. I'm sorry the work was done via a private github account at first, but that was a temporary measure to help the several big companies reach consensus and buy into the long-term cooperative game that must be played to pull this off.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by jmorris on Saturday June 20 2015, @07:01AM

    by jmorris (4844) on Saturday June 20 2015, @07:01AM (#198565)

    This thing is stated as intending to diverge from stock JS so the only reason it isn't going to require a plugin is that Firefox, Google and Microsoft apparently intend to just bundle the VM into their browser products. Since they account for essentially 100% of the browser market at present this will be a seamless thing if it comes off as planned. But so would bundling a JVM into the browser and not requiring the downloading of a plugin. See the problem I'm having understanding why this is required? Several production grade JVMs already exist, have been tested in the real world for years and have had a multitude of security holes patched. Compared to a new effort with none of that track record.

    And in the end it is all pointless anyway. This is just the Java dream yet again, of write once, run anywhere. Never works. The only way to come close is to assume a least common denominator system and those are always too limiting. Next thing you know you have to platform specific hooks. Some have mice, some touch, some multi-touch. Some have other sensors. iOS exposes different APIs than Android, Windows is different from OSX and from Linux. So more platform specific code or massive frameworks to abstract it away... and those have their own problems. So And so on. Bottom line is that if each platform didn't have something unique to it there probably wouldn't be so many platforms in the first place.

    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by prospectacle on Saturday June 20 2015, @07:43AM

    by prospectacle (3422) on Saturday June 20 2015, @07:43AM (#198574) Journal

    You may be right about existing VMs. I don't know enough about them.

    Would JVM be able to run javascript efficiently so that the new system could be backwards compatible with old web pages. I'm assuming this proposed WASM engine will, once released, compile javascript to bytecode if the page contains javascript (and maybe do the same for several other languages), or run bytecode directly if the page contains bytecode.

    Regarding the "dream of java" that never works, I would argue that javascript has gotten far closer to realising this ideal than java ever did (or ever will). Of course it's far from perfect.

    Regarding platform differences, they definitely exist, and create all kinds of work, but people work around them. Many web pages will adapt to the resources available and some are even quite good at doing this. The size (and amount, and resolution) of what's displayed on the screen at once, the user input that's required (whether from touch, swipe, type, etc), the framerate, and layout might all be adjusted according to your screen size, effective processor performance, graphics power, input hardware, etc.

    Whether or not we have a bytecode interpreter for browsers is probably not going to affect whether or not the web remains the "Write once, run anywhere" plaform of choice, but it might make the performance better.

    I don't know if existing VMs would be better suited but I suspect one of the reason to make a new one (besides novelty and PR value) is to make sure it can be optimised to support existing javascript, DOM operations, etc.

    --
    If a plan isn't flexible it isn't realistic
  • (Score: 1) by Pino P on Saturday June 20 2015, @02:45PM

    by Pino P (4721) on Saturday June 20 2015, @02:45PM (#198690) Journal

    Firefox, Google and Microsoft apparently intend to just bundle the VM into their browser products. Since they account for essentially 100% of the browser market at present

    Apple accounts for 100 percent of the browser engine market on iOS. Did you mean that iOS itself accounts for "essentially" 0 percent of the overall market?

    Several production grade JVMs already exist

    How much do these JVMs' publishers pay Oracle to license Java?

    • (Score: 2) by jmorris on Saturday June 20 2015, @03:27PM

      by jmorris (4844) on Saturday June 20 2015, @03:27PM (#198709)

      Actually Apple allows browsers into the App Store now. So you can get Chrome, Opera, etc. but not Firefox (yet) on iOS. On the desktop you can get both Chrome and Firefox along with a host of others. You just can't get IE anymore and probably won't have whatever Project Spartan ships as either.

      But yea Apple isn't exactly downstream with WebKit anymore so if they decided to be difficult they could be the turd in the punchbowl so you have a valid point in that I ignored that possibility. However I doubt they would, if everyone else adds support for a new web standard they will follow. If they already have Moz Corp, Microsoft and Google on board expect Apple to start contributing soon.

      As for Java, at this point I suspect Oracle would bust a nut at the offer to get a JVM into every browser even if it didn't include the whole 'Java' API set, only the VM and bindings to the DOM. Perhaps the fatal fight would be Google wanting their alternate VM?

      • (Score: 2, Informative) by Pino P on Saturday June 20 2015, @04:41PM

        by Pino P (4721) on Saturday June 20 2015, @04:41PM (#198731) Journal

        Actually Apple allows browsers into the App Store now.

        The last time I checked, third-party web browsers for iOS, such as Chrome and Opera, were shells around the UIWebView or (since iOS 8) WKWebView class shipped with iOS. Both of these classes are Apple WebKit. You can't get Firefox because Mozilla doesn't want to dilute the "Firefox" brand with a browser not based on Gecko.

        Gecko does not run on iOS because iOS policy prohibits Spidermonkey and all other third-party JIT engines. In iOS, all non-Apple code executes under a strict W^X policy. Only the system executable loader is allowed to populate an executable page. A desktop application can ask the memory manager to flip a page from writable and not executable to executable and not writable, and a JIT engine will flip a page after filling it with code. But this operation is forbidden to non-Apple executables on iOS. This means no HotSpot JVM, no CLR, no Google V8, no Google Native Client, and no Mozilla Spidermonkey.

  • (Score: 2) by JNCF on Saturday June 20 2015, @06:36PM

    by JNCF (4317) on Saturday June 20 2015, @06:36PM (#198765) Journal

    From Eich:

    It’s crucial that wasm and asm stay equivalent for a decent interval, to support polyfilling of wasm support via JS. This remains crucial even as JS and asm.js evolve to sprout shared memory threads and SIMD support. Examples of possible longer-term divergence: zero-cost exceptions, dynamic linking, call/cc. Yes, we are aiming to develop the Web’s polyglot-programming-language object-file format.

    It doesn't need wide acceptance in the beginning, if your browser supports ECMAScript then WebAssembly will work. Not that you could have this with a JVM. [github.io]