> Why Mozilla or Apple didn't go with a multiprocessing model for tabbed browsing in the > first place is beyond me.
At least in part because multi-processing was a much more serious resource issue say about 10 years ago (when Gecko was initially being developed). Also most likely because it's more work that way. Especially where getting plug-ins to work is concerned. I think there's general agreement that moving in that direction is a good idea; the question is how to get there given the existing code...
Not really. The current plan is to use the same JIT backend (nanojit), but the interpreters are staying separate. See the typed vs untyped issue I mention elsewhere for why.
Note that Spidermonkey (the Js engine in Gecko) already has a precise (though not incremental) GC. At least on the JavaScript side. The C++ bits that implement the DOM use reference counting, with a GC-like layer on top of that that detects cycles.
Does your compiler produce typed code for Flash and untyped for Javascript? Note that typical web code is untyped, and on untyped code the Flash Javascript interpreter is pretty slow, since ActionScript is typically typed.
> The rich control 99% of our wealth, yet they pay ONLY 80% of our taxes.
Please cite? In particular, make sure that both statistics are using the same definition of "the rich".
Last I'd checked, the net effect of our super-complicated personal income tax system was in fact pretty much equivalent to a flat tax on wealth. I believe the Wikipedia articles on the US tax system has some relevant numbers. It certainly used to.
By "figure out" do you mean "decide which app to hand it off to"?
There used to be a standard for that on *nix: mailcap files. Then GNOME and KDE did their own things that differ from that, leaving apps to deal with the resulting mess. Firefox will ask GNOME for handler info, then fall back on mailcap files. I keep hearing that GNOME and KDE will get their acts together and converge on something where if you set up a handler in KDE the GNOME API for getting a handler will see it... but until that happens, apps are stuck either talking to just one of them or having to duplicate a bunch of code. And Firefox does happen to be a GNOME app for the most part. There have been several KDE ports of it, but no one's ever stepped up to maintain them, unlike the GNOME code (lack of interest from the KDE community?), so they withered and died.
In any case, the right solution here is a sane OS-level MIME registry, not every app having to query umpteen bazillion MIME registries du jour.
Other than the advantage of being able to run on multiple cores at once (also possible with threads instead of processes, but threads involve a lot of pain, though different pain from gluing together processes) and not having to reimplement a task scheduler, since the OS presumably has a perfectly serviceable one.
If content script could access chrome, it could do all sorts of bad things (like reading your hard drive). So while you're right that a bug could grant such access, those sorts of bugs are stop-the-presses-and-fix-this firedrills.
> whats to stop mozilla from lining its pockets with some nice targeted advertising?
Probably nothing other than a sense of ethics. Of course Firefox already knows the list of URLs you visit as well as their full contents, so it seems you're trusting it to not misuse this information as things stand, no?
All the code is already compiled up front into bytecode.
Further compiling to native code would actually be a bit of a pain due to the type polymorphism of JS. It could be done, but the result would take a good bit of memory and wouldn't be as fast as it could be.
Using the tracing JIT compiler reduces memory usage while improving performance, as well as speeding up pageload time, compared to a "compile it all up front" approach.
I'm not desirous of failure. I'm reluctant to claim perfection where it's unlikely to exist, and realistic in terms of the amount of effort required to attain perfection.
If you've never read it, I recommend . It's not that the situation is satisfactory, it's just that shipping imperfect software is usually better than shipping nothing.
A lot of life is like that. That doesn't eliminate aspiration, it just means you have to make tradeoffs in practice.
The real problem is unexpected interactions between the many different things that need to happen... and the fact that thinking through all of them ahead of time is impossible due to combinatorial growth.
Seriously, designing a robust, fast system (using limited resources!) that has to do more than about one thing is very very difficult. I would claim impossible.
Note that 10.3.x has also been dropped by Apple. They no longer issue patches for security issues for it... This was the key factor in deciding it was OK to drop support for it (there were strong arguments for dropping support, but this was the thing that decided people that it was actually OK).
The current browser should be secure, yes. But people keep finding new attack vectors, and it turns out that building a large secure system is kinda hard. Which means slow, expensive, or both, and probably still not successful.
So in practice modern software tends to have continuous fixes made to it to improve security. But Firefox 3 and Firefox 2 are different enough under the hood, that it's getting to the point that it's a matter of making fixes for one or the other but not both. Given that choice, how would you choose?
The upgrade shouldn't be offered to users of FC4, for what it's worth.
As for instructions... you would need to compile statically against GTK, basically. And current pango, probably.
And nag your distribution vendors and the GTK folks to stop changing stuff so much all the time that it's impossible to integrate well with a current GTK-based desktop while keeping support for something with the a vintage as recent as FC4.
Red Hat is porting Firefox 3 to RHEL 4, last I checked.
With Fedora Core 4, you're sort of on your own. You can stick with Fx2 and security bugs... just like you're sticking with other not-getting-updates packages and security bugs.
In general, the Linux mess with Firefox 3 is largely to do with the fact that people wanted all sorts of stuff system-integration wise that the GTK version shipped with Fedora Core 4, say, just couldn't do. In other words, it's hard to integrate with a half-baked desktop (which is sort of where Linux still is): it doesn't provide the hooks you need.
Simple little things like "use the same fonts as the user's other apps" work fundamentally differently between FC4 and FC9, for example. Now you could claim that Mozilla should maintain two completely different sets of code to handle this, but it was decided that this wasn't worth it. Especially because 95%+ of all Linux Firefox users just get it from their distribution, not from Mozilla.org.
Slashdot Mirror
> Why Mozilla or Apple didn't go with a multiprocessing model for tabbed browsing in the
> first place is beyond me.
At least in part because multi-processing was a much more serious resource issue say about 10 years ago (when Gecko was initially being developed). Also most likely because it's more work that way. Especially where getting plug-ins to work is concerned. I think there's general agreement that moving in that direction is a good idea; the question is how to get there given the existing code...
I think the Boehm collector is being looked into for the C++ code (to replace reference-counting), but the JS GC is a separate setup.
Right now it can't move objects around, as I recall, but I'm told it might not be too hard to implement if needed.
One process per tab is exactly what IE8 is doing.
> AIUI, haXe itself is strong, statically typed with type inference
Given that, I would bet money it's generating typed code for Flash.
Not really. The current plan is to use the same JIT backend (nanojit), but the interpreters are staying separate. See the typed vs untyped issue I mention elsewhere for why.
Note that Spidermonkey (the Js engine in Gecko) already has a precise (though not incremental) GC. At least on the JavaScript side. The C++ bits that implement the DOM use reference counting, with a GC-like layer on top of that that detects cycles.
Does your compiler produce typed code for Flash and untyped for Javascript? Note that typical web code is untyped, and on untyped code the Flash Javascript interpreter is pretty slow, since ActionScript is typically typed.
> The rich control 99% of our wealth, yet they pay ONLY 80% of our taxes.
Please cite? In particular, make sure that both statistics are using the same definition of "the rich".
Last I'd checked, the net effect of our super-complicated personal income tax system was in fact pretty much equivalent to a flat tax on wealth. I believe the Wikipedia articles on the US tax system has some relevant numbers. It certainly used to.
Oh, and Ben in particular hasn't been involved in Firefox development for about 2 years now. I guess you can call that "until recently". ;)
By "figure out" do you mean "decide which app to hand it off to"?
There used to be a standard for that on *nix: mailcap files. Then GNOME and KDE did their own things that differ from that, leaving apps to deal with the resulting mess. Firefox will ask GNOME for handler info, then fall back on mailcap files. I keep hearing that GNOME and KDE will get their acts together and converge on something where if you set up a handler in KDE the GNOME API for getting a handler will see it... but until that happens, apps are stuck either talking to just one of them or having to duplicate a bunch of code. And Firefox does happen to be a GNOME app for the most part. There have been several KDE ports of it, but no one's ever stepped up to maintain them, unlike the GNOME code (lack of interest from the KDE community?), so they withered and died.
In any case, the right solution here is a sane OS-level MIME registry, not every app having to query umpteen bazillion MIME registries du jour.
> The most significant part of this news may be that Google is pulling people off Firefox
> development
They did pull basically everyone they had working on Firefox off of it. That happened about 2 years ago, plus/minus a few months.
Other than the advantage of being able to run on multiple cores at once (also possible with threads instead of processes, but threads involve a lot of pain, though different pain from gluing together processes) and not having to reimplement a task scheduler, since the OS presumably has a perfectly serviceable one.
If content script could access chrome, it could do all sorts of bad things (like reading your hard drive). So while you're right that a bug could grant such access, those sorts of bugs are stop-the-presses-and-fix-this firedrills.
> whats to stop mozilla from lining its pockets with some nice targeted advertising?
Probably nothing other than a sense of ethics. Of course Firefox already knows the list of URLs you visit as well as their full contents, so it seems you're trusting it to not misuse this information as things stand, no?
All the code is already compiled up front into bytecode.
Further compiling to native code would actually be a bit of a pain due to the type polymorphism of JS. It could be done, but the result would take a good bit of memory and wouldn't be as fast as it could be.
Using the tracing JIT compiler reduces memory usage while improving performance, as well as speeding up pageload time, compared to a "compile it all up front" approach.
> Uh, why do you have any significant memory overhead?
Because you have to have the original bytecode as well as the jitted code?
> Even badly optimized code should be pretty compact
I think you're severely underestimating the amount of JS modern web pages serve up and how big it ends up when jitted...
> True, but modern processors handle call/ret well.
Perhaps, but pushing all the args and popping the return values takes time.
In any case, as I said the true test would be doing both approaches and comparing.
I'm surprised the paper doesn't discuss these tradeoffs, though. Or does it?
I'm not desirous of failure. I'm reluctant to claim perfection where it's unlikely to exist, and realistic in terms of the amount of effort required to attain perfection.
If you've never read it, I recommend . It's not that the situation is satisfactory, it's just that shipping imperfect software is usually better than shipping nothing.
A lot of life is like that. That doesn't eliminate aspiration, it just means you have to make tradeoffs in practice.
The real problem is unexpected interactions between the many different things that need to happen... and the fact that thinking through all of them ahead of time is impossible due to combinatorial growth.
Seriously, designing a robust, fast system (using limited resources!) that has to do more than about one thing is very very difficult. I would claim impossible.
> In terms of total runtime, the common case is that the Javascript is inner loop code.
Indeed, and the idea is that once you run a loop a few times you jit it.
> Even if the JIT translator is slower than a few passes through the interpreter, why are
> you caring so much about code that barely matters?
Because there is memory overhead to jitting everything, even things you don't hit.
Also, jitting evething (standard function-level jit) means you have to actually keep the function calls. Tracing effectively inlines everything.
It's not obvious which is better, I agree. At least at first glance. It would be best to have both done and compare!
I believe that the type checks are in fact done when the type might change, not on read.
Note that 10.3.x has also been dropped by Apple. They no longer issue patches for security issues for it... This was the key factor in deciding it was OK to drop support for it (there were strong arguments for dropping support, but this was the thing that decided people that it was actually OK).
What made you think that? The update won't be offered on OSX 10.4. Give people some credit for not being morons, eh?
That's what they're doing.
The current browser should be secure, yes. But people keep finding new attack vectors, and it turns out that building a large secure system is kinda hard. Which means slow, expensive, or both, and probably still not successful.
So in practice modern software tends to have continuous fixes made to it to improve security. But Firefox 3 and Firefox 2 are different enough under the hood, that it's getting to the point that it's a matter of making fixes for one or the other but not both. Given that choice, how would you choose?
The upgrade shouldn't be offered to users of FC4, for what it's worth.
As for instructions... you would need to compile statically against GTK, basically. And current pango, probably.
And nag your distribution vendors and the GTK folks to stop changing stuff so much all the time that it's impossible to integrate well with a current GTK-based desktop while keeping support for something with the a vintage as recent as FC4.
Red Hat is porting Firefox 3 to RHEL 4, last I checked.
With Fedora Core 4, you're sort of on your own. You can stick with Fx2 and security bugs... just like you're sticking with other not-getting-updates packages and security bugs.
In general, the Linux mess with Firefox 3 is largely to do with the fact that people wanted all sorts of stuff system-integration wise that the GTK version shipped with Fedora Core 4, say, just couldn't do. In other words, it's hard to integrate with a half-baked desktop (which is sort of where Linux still is): it doesn't provide the hooks you need.
Simple little things like "use the same fonts as the user's other apps" work fundamentally differently between FC4 and FC9, for example. Now you could claim that Mozilla should maintain two completely different sets of code to handle this, but it was decided that this wasn't worth it. Especially because 95%+ of all Linux Firefox users just get it from their distribution, not from Mozilla.org.
No. The update won't be offered on OSes where it can't run. That includes Mac OS X 10.3 and earlier, and Windows 98/ME.