Write XOR Execute JIT Support Lands For Mozilla Firefox

[pal666]

not to mention optimizations that are only possible when analyzing code from completely different tabs/JS together

it will make code which is slow for every tab instead of several codes each fast for its own

[pal666]

It's not only a memory hit. Imagine you open 10 tabs on facebook. Each tab will run largely the same Javascript, but each will have to compile it to native code separately

global engine still has to compile it separately or to employ some cache. make that cache shared by instances and your problem is solved

[pal666]

this w^x thing was named by some uneducated kid who dind't know that 0^0=0

The thing is, spawning a JIT engine instance per tab will improve performance, but it will eat your RAM, too (which is what Chrome is doing).

it's easy to fix - it shouldn't have much per-instance data

[bug77]

Well, mozilla always knows when to innovate and how to do it right. They have great technical expertise. And if someone haven't got it, I'm utterly sarcastic here...

Can you name the browser that broke IE's stranglehold on the www? Hint: it wasn't Chrome, Opera or Safari (though in all honesty, Opera invented more than anyone else). Maybe they don't have the resources to do it again, but at least at one point Mozilla was the master of the game.
milkylainen W^X being moot because of ROP is like saying locking your door is moot because since you've started doing it, burglars are entering through the window.

[SystemCrasher]

Yeah. I know. I was just saying, W^X will not stop ROP's. Nowdays writing ROP's is pretty commonplace.

OTOH, on ARM, ROP/ret2libc/etc is quite a PITA to perform and wide use of ASLR for all libs and apps can get it even worse :]

[SystemCrasher]

W^X does not add much security. These days ROP's have become commonplace.. W^X nigh on a moot point.

Well, mozilla always knows when to innovate and how to do it right. They have great technical expertise. And if someone haven't got it, I'm utterly sarcastic here...

[bug77]

I see. Thanks for the explanation.
Four of the five traditional computers in my house have 12GB of RAM or more, so I'd take the memory hit for the performance boost. But since consumer laptops and desktops with just 4GB or even in many cases just 2GB of RAM are still shockingly common, I guess the Mozilla team has very reasonably made the choice that fits the largest number of end users.

It's not only a memory hit. Imagine you open 10 tabs on facebook. Each tab will run largely the same Javascript, but each will have to compile it to native code separately. That's CPU overhead and will bite you hard on mobile. If there was one engine, code could be compiled once and then reused (not to mention optimizations that are only possible when analyzing code from completely different tabs/JS together). But hey, that's why engineering is fun.
As it is, if you're a heavy user, then you have to use Chrome, if you're a light user, you can use whatever browser you want. I'm sure a unified solution will emerge eventually, but it will be a while. In the meantime, I think that if you understand the status quo, you can still make a sensible choice. Thank God (and Mozilla) we're not living in the IE5 age anymore.

[Michael_S]

The thing is, spawning a JIT engine instance per tab will improve performance, but it will eat your RAM, too (which is what Chrome is doing). So it's really hard to say which would be the right thing to do here. Probably (otoh) keeping a single instance, but adding some sort of a reactive nature to it so that it can serve many clients (aka tabs) without a performance penalty. But this would be really tough to implement right.

I see. Thanks for the explanation.
Four of the five traditional computers in my house have 12GB of RAM or more, so I'd take the memory hit for the performance boost. But since consumer laptops and desktops with just 4GB or even in many cases just 2GB of RAM are still shockingly common, I guess the Mozilla team has very reasonably made the choice that fits the largest number of end users.

[bug77]

Ooh, thanks for that explanation. I had not understood that distinction, and I was puzzled why Firefox did so well in benchmarks but did not seem quicker than Chrome in heavy multi-tab usage. That explains it.

I believe Firefox is still quick enough that it's not a burden to use it.

So is there a "part two" of the Firefox Electrolysis project to address this? Or is the long term solution to this problem part of the Servo project?

The thing is, spawning a JIT engine instance per tab will improve performance, but it will eat your RAM, too (which is what Chrome is doing). So it's really hard to say which would be the right thing to do here. Probably (otoh) keeping a single instance, but adding some sort of a reactive nature to it so that it can serve many clients (aka tabs) without a performance penalty. But this would be really tough to implement right.

[Michael_S]

Semi-wrong. Mozilla's Spidermonkey is actually faster than V8 in many cases, but the slowness of Firefox comes not from the layout engine, but from the fact that all tabs (and interface) uses one instance of spidermonkey. As fast as it is, it can't show off if more than one tab is opened.

Ooh, thanks for that explanation. I had not understood that distinction, and I was puzzled why Firefox did so well in benchmarks but did not seem quicker than Chrome in heavy multi-tab usage. That explains it.

I believe Firefox is still quick enough that it's not a burden to use it.

So is there a "part two" of the Firefox Electrolysis project to address this? Or is the long term solution to this problem part of the Servo project?