1) TraceMonkey turned out to have very uneven performance. This was partly because it type-specialized very aggressively, and partly because it didn't deal well with very branchy code due to trace-tree explosion. As a result, when it was good it was really good (for back then), but when it hit a case it didn't handle well it was awful. JaegerMonkey was added as a way to address these shortcomings by having a baseline compiler that handled most cases, reserving tracing for very hot type-specialized codepaths.
2) As work on JaegerMonkey progressed and as Brian Hackett's type inference system was being put in place, it turned out that JaegerMonkey + type inference could give performance similar to TraceMonkey, with somewhat less complexity than supporting both compilers on top of type inference. So when TI was enabled, TraceMonkey was switched off, and later removed from the tree. But keep in mind that JaegerMonkey was designed to be a baseline JIT: run fast, compile everything, no fancy optimizations.
3) IonMonkey exists to handle the cases TraceMonkey used to do well. It has a much slower compilation pass than JaegerMonkey, because it does more involved optimizations. So most code gets compiled with JaegerMonkey, and then particularly hot code is compiled with IonMonkey.
This is a common design for JIT systems, actually: a faster JIT that produces slower code and a slower JIT that produces faster code for the cases where it matters.
The fact that there is no 64-bit MSVC compiler that can produce 32-bit binaries has certainly been a problem for a number of people. It means that trying to do PGO on a large codebase being compiled into a 32-bit binary runs out of address space. Both Mozilla and Google have run into this, for example; in Google's case the result was them not using PGO at all.
Fixing all the bugs introduced by the different compiler that you haven't worked around yet, then fixing all the issues due to the 64-bit plug-ins (esp Flash) having a different set of problems than the 32-bit ones, then fixing any remaining issues due to Windows-specific code possibly making dumb assumptions about sizes of things is a different matter altogether.
Which is why 64-bit nightlies _existed_. They just don't work that well, on average.
Then the question becomes whether to make (and test, which causes even more load on the test infrastructure) these builds, which no one plans to ship to actual end users anytime in the next 6+ months. That's what the discussion was really about: does Mozilla keep spending time keeping these builds limping even though they don't have the time to make them actually tier-1, or do they just stop doing them for now and start again when they have the resources to actually do it right?
The amount of effort needed to support multiple versions of OSX at the same time is much larger than the amount of effort needed on Windows, because Microsoft usually bends over backwards to not break compat, while Apple will go out of its way to do so.
Combined with the lower user base on Mac and the faster OS update cycle of Mac users, this means that dropping support for old MacOS versions is a much simpler call than dropping support for old Windows versions: They're more work to support, and the number of users using them is much smaller.
For perspective, about half of Mozilla's Windows users are still on WinXP (which approximately matches the overall fraction of Windows users on WinXP), while the fraction of Mac users on 10.5 was 10% and falling rapidly when support was dropped.
A serious question: why do you want WebP support? What does it buy you?
The blog post at http://muizelaar.blogspot.com/2011/04/webp.html explains why Mozilla is not likely to support WebP in its current state, but if there's something Jeff missed it might be worth letting him know...
Ah, 350MB in task mgr would match the ~400MB resident metrics from about:memory.
And again, about 100MB of that is not even Firefox itself...
For the rest, the basic problem is that web sites are doing a _lot_ of JS, as are the extensions you have installed. So they're using a lot of memory for all those JS objects.:(
It would be interesting to see how much memory other browsers use on that set of sites, for what it's worth.
That's showing about 400MB RAM usage, and about 800MB address space. But address space includes mmapped files and reserved address space that is not actually backed by memory; it only matters for purposes of running out of a 32-bit process's 4GB address space.
So OK, 400MB memory usage. Of this, about 260MB was actually allocated by the browser (see "explicit"; the rest seems to be things the OS is putting into the process memory space space (e.g. the code of the browser, the code of the libraries the browser links to, etc).
Of this 260MB, looks like about 70MB is RAM used by your extensions (17MB for adblock plus, 6MB for https-everywhere, etc). Another 30MB looks like it might be JS GC heap fragmentation from those extensions.
Another 40MB is the yahoo mail tab; almost all of this is the various JS gunk it's doing.
7MB is Wired.
About 6MB for Slashdot.
Another 5MB for about:addons, and about 15MB for the browser UI.
30MB unknown to about:memory.
16MB in-memory cache for the bookmarks and history databases.
10MB images.
7MB web workers used by ghostery.
That accounts for most of the memory listed as far as I can tell.
Which tabs? Note that some web apps keep allocating more and more memory until you reload the page (e.g. Google Reader will do this) because they "cache" all sorts of stuff in global variables and whatnot.
So it's pretty easy to hit 800MB in all browsers with 5-6 tabs, especially if you leave them open for a while.:(
That said, I'd be interested in how the output of about:compartments for you compares to the list of 5-6 tabs you have open. What does about:memory say about where the memory is being used?
Uh... Chrome needs Android 4.0. There's no way you're running Chrome on a 2.2 tablet.;)
What's the actual tablet model, if you're willing to say? I'll see if I can figure out why you can't install it. Also, what version did you try installing?
Andy, what Android version do you have? Firefox runs on 2.2 and above, which according to http://en.wikipedia.org/wiki/Android_(operating_system)#Usage_share as of today covers about 96% of Android devices. It's possible you're in the 4%, but it's also possible that your real problem is your processor, not your Android version. If so (if you're using an armv6 processor), there is ongoing work to make Firefox work on those that should hopefully ship in late November.
> but it doesn't change (aka "break") anything each > time.
Except that it does, of course. It breaks websites all the time, for example, just like every other browser that makes any sort of change to its rendering engine.
I think your understanding is wrong. See https://blog.mozilla.org/blog/2012/07/02/firefox-mobile-os/ (yes, it's basically a press release, but it's a convenient one-stop shop for a list of people who have plans, theoretical or not, to ship Firefox OS devices).
It's running directly on top of a Linux kernel. No real userland other than Gecko and whatever drivers run in user space, from the kernel's point of view.
html5test.com doesn't test all parts of HTML5. And it tests things that aren't part of HTML5 and never will be.
Basically, it tests whatever the test author felt like testing. Often incorrectly (e.g. giving a pass when the feature is completely broken or giving a fail when the feature is actually implemented because the test is not testing for it correctly). Sometimes the bugs in the test are fixed when pointed out. Sometimes not.
The real test is whether things that people care about are supported, not what the score on html5test.com is. Which then depends on what things people care about.
So are there specific parts of HTML5 that you've tried using recently that are not supported by Gecko?
(Full disclosure: Have contributed to Gecko, have worked on some web standards stuff, have contributed a bit to WebKit, etc.)
Slashdot Mirror
A short summary:
1) TraceMonkey turned out to have very uneven performance. This was partly because it type-specialized very aggressively, and partly because it didn't deal well with very branchy code due to trace-tree explosion. As a result, when it was good it was really good (for back then), but when it hit a case it didn't handle well it was awful. JaegerMonkey was added as a way to address these shortcomings by having a baseline compiler that handled most cases, reserving tracing for very hot type-specialized codepaths.
2) As work on JaegerMonkey progressed and as Brian Hackett's type inference system was being put in place, it turned out that JaegerMonkey + type inference could give performance similar to TraceMonkey, with somewhat less complexity than supporting both compilers on top of type inference. So when TI was enabled, TraceMonkey was switched off, and later removed from the tree. But keep in mind that JaegerMonkey was designed to be a baseline JIT: run fast, compile everything, no fancy optimizations.
3) IonMonkey exists to handle the cases TraceMonkey used to do well. It has a much slower compilation pass than JaegerMonkey, because it does more involved optimizations. So most code gets compiled with JaegerMonkey, and then particularly hot code is compiled with IonMonkey.
This is a common design for JIT systems, actually: a faster JIT that produces slower code and a slower JIT that produces faster code for the cases where it matters.
https://blog.mozilla.org/dmandelin/2011/04/22/mozilla-javascript-2011/ has a bit of discussion about some of this.
That's not quite true.
TraceMonkey has in fact been removed, and JaegerMonkey may be too once the new baseline JIT being worked on now is done.
The fact that there is no 64-bit MSVC compiler that can produce 32-bit binaries has certainly been a problem for a number of people. It means that trying to do PGO on a large codebase being compiled into a 32-bit binary runs out of address space. Both Mozilla and Google have run into this, for example; in Google's case the result was them not using PGO at all.
Compiling is easy in a vacuum,
Fixing all the bugs introduced by the different compiler that you haven't worked around yet, then fixing all the issues due to the 64-bit plug-ins (esp Flash) having a different set of problems than the 32-bit ones, then fixing any remaining issues due to Windows-specific code possibly making dumb assumptions about sizes of things is a different matter altogether.
Which is why 64-bit nightlies _existed_. They just don't work that well, on average.
Then the question becomes whether to make (and test, which causes even more load on the test infrastructure) these builds, which no one plans to ship to actual end users anytime in the next 6+ months. That's what the discussion was really about: does Mozilla keep spending time keeping these builds limping even though they don't have the time to make them actually tier-1, or do they just stop doing them for now and start again when they have the resources to actually do it right?
The amount of effort needed to support multiple versions of OSX at the same time is much larger than the amount of effort needed on Windows, because Microsoft usually bends over backwards to not break compat, while Apple will go out of its way to do so.
Combined with the lower user base on Mac and the faster OS update cycle of Mac users, this means that dropping support for old MacOS versions is a much simpler call than dropping support for old Windows versions: They're more work to support, and the number of users using them is much smaller.
For perspective, about half of Mozilla's Windows users are still on WinXP (which approximately matches the overall fraction of Windows users on WinXP), while the fraction of Mac users on 10.5 was 10% and falling rapidly when support was dropped.
A serious question: why do you want WebP support? What does it buy you?
The blog post at http://muizelaar.blogspot.com/2011/04/webp.html explains why Mozilla is not likely to support WebP in its current state, but if there's something Jeff missed it might be worth letting him know...
Sounds like a JavaScriptCore bug. There are no readonly properties in sight around that line...
Ah, 350MB in task mgr would match the ~400MB resident metrics from about:memory.
And again, about 100MB of that is not even Firefox itself...
For the rest, the basic problem is that web sites are doing a _lot_ of JS, as are the extensions you have installed. So they're using a lot of memory for all those JS objects. :(
It would be interesting to see how much memory other browsers use on that set of sites, for what it's worth.
That's showing about 400MB RAM usage, and about 800MB address space. But address space includes mmapped files and reserved address space that is not actually backed by memory; it only matters for purposes of running out of a 32-bit process's 4GB address space.
So OK, 400MB memory usage. Of this, about 260MB was actually allocated by the browser (see "explicit"; the rest seems to be things the OS is putting into the process memory space space (e.g. the code of the browser, the code of the libraries the browser links to, etc).
Of this 260MB, looks like about 70MB is RAM used by your extensions (17MB for adblock plus, 6MB for https-everywhere, etc). Another 30MB looks like it might be JS GC heap fragmentation from those extensions.
Another 40MB is the yahoo mail tab; almost all of this is the various JS gunk it's doing.
7MB is Wired.
About 6MB for Slashdot.
Another 5MB for about:addons, and about 15MB for the browser UI.
30MB unknown to about:memory.
16MB in-memory cache for the bookmarks and history databases.
10MB images.
7MB web workers used by ghostery.
That accounts for most of the memory listed as far as I can tell.
Which tabs? Note that some web apps keep allocating more and more memory until you reload the page (e.g. Google Reader will do this) because they "cache" all sorts of stuff in global variables and whatnot.
So it's pretty easy to hit 800MB in all browsers with 5-6 tabs, especially if you leave them open for a while. :(
That said, I'd be interested in how the output of about:compartments for you compares to the list of 5-6 tabs you have open. What does about:memory say about where the memory is being used?
1) Users of Firefox OS
2) You're assuming the apps are not free as in beer. A number of them will be, of course. That's true in both the Android and Apple stores...
Uh... Chrome needs Android 4.0. There's no way you're running Chrome on a 2.2 tablet. ;)
What's the actual tablet model, if you're willing to say? I'll see if I can figure out why you can't install it. Also, what version did you try installing?
Andy, what Android version do you have? Firefox runs on 2.2 and above, which according to http://en.wikipedia.org/wiki/Android_(operating_system)#Usage_share as of today covers about 96% of Android devices. It's possible you're in the 4%, but it's also possible that your real problem is your processor, not your Android version. If so (if you're using an armv6 processor), there is ongoing work to make Firefox work on those that should hopefully ship in late November.
http://www.mozilla.org/en-US/firefox/mobile/platforms/ says Firefox for Android runs on 2.2.
When the decision to pull was made, the schedule for 16.0.1 was already known.
Sweet time? It was fixed yesterday, hours after it was discovered; builds should be coming out today.
If you see incorrect things ... it's a wiki. Fix them. I certainly plan to, which I can't do with w3schools!
Except with any luck unlike w3schools it won't have incorrect information on it because people will be able to fix it like any other wiki.
The big problem with w3schools is that there's all sorts of mistakes on there and they won't fix things if you point out the problems.
You _want_ Firefox to uninstall or upgrade random other software on the computer without asking the user?
Most people don't want their software doing that sort of thing...
> but it doesn't change (aka "break") anything each
> time.
Except that it does, of course. It breaks websites all the time, for example, just like every other browser that makes any sort of change to its rendering engine.
I think your understanding is wrong. See https://blog.mozilla.org/blog/2012/07/02/firefox-mobile-os/ (yes, it's basically a press release, but it's a convenient one-stop shop for a list of people who have plans, theoretical or not, to ship Firefox OS devices).
Does about:support say anything useful about why WebGL is not enabled for you?
Part of the REC process involves having two browsers agreeing on the implementation of every HTML5 feature. How long do you expect this to take?
It also involves writing a test suite to ensure that this is actually happening. Contributed any tests to tha recently?
It's running directly on top of a Linux kernel. No real userland other than Gecko and whatever drivers run in user space, from the kernel's point of view.
html5test.com doesn't test all parts of HTML5. And it tests things that aren't part of HTML5 and never will be.
Basically, it tests whatever the test author felt like testing. Often incorrectly (e.g. giving a pass when the feature is completely broken or giving a fail when the feature is actually implemented because the test is not testing for it correctly). Sometimes the bugs in the test are fixed when pointed out. Sometimes not.
The real test is whether things that people care about are supported, not what the score on html5test.com is. Which then depends on what things people care about.
So are there specific parts of HTML5 that you've tried using recently that are not supported by Gecko?
(Full disclosure: Have contributed to Gecko, have worked on some web standards stuff, have contributed a bit to WebKit, etc.)