10 ms·

MemShrink progress report, week 23

211 points by llambda 15y ago

AndrewDucker 15y ago
I know people like to complain about the new rapid release cycle, but there's been a definite upswing in the work going on on Mozilla since it started. I wonder if knowing that your code will be on people's desktops in three months rather than two years makes a big difference.
- Pheter 15y ago
  Does Firefox plan to use the same style of forced updates that Chrome does? As a web developer I am very grateful that Chrome is not only updated regularly but that these updates are forced on the end user. IE10 could be the best browser ever, but unfortunately there will still be people using IE7.
  - richbradshaw 15y ago
    It already does I believe, or at least, they are hard to not accept.
  - smspence 15y ago
    I believe automatic, silent updates are coming in Firefox 10.
    - eiji 15y ago
      I don't see silent updates in FF10 yet. True silent ones are only possible if you move the install into the Roaming area, otherwise win7 with resonable security settings will ask for confirmation. From what I know, IT-departments don't like that.
      - joelhaasnoot 15y ago
        IT departments need to stop complaining and get their act together. That, and enterprise software firms should stop charging an arm and a leg for updates, and stop making software that will only run in IE (6). If you buy that software, shout at your boss, not at Firefox or Chrome.
      - nl 15y ago
        From what I know, IT-departments don't like that. It's important to note that, yes, it is true that some IT department are reactionary and dislike the new release process, BUT that doesn't mean that are right. There are plenty of analogous automatic update systems which are used every day in IT departments. Virus checkers are the canonical example, but increasingly SAAS applications are the same. Many IT departments are stuck in a 1999 mode of trying to control the exact version of every software they run. Fortunately businesses are wising up - firstly IT tried to tell them they couldn't use iPhone because they "weren't approved". That worked until the CEO demanded one. Now some try and say rapid browser versioning and automatic releases are bad. They'll get over that, too, or otherwise they'll be ignored. (And don't bring up the example of the IE6 websites that must use IE6 forever more. That's a problem to solve, not an excuse for keeping an entire enterprise locked to outdated technology.)
        eitally 15y ago
        You're just wrong. There are several very good reasons why the 1999 mode is both useful and important, at least for the time being (and the next several years). Here is a brief list: - Cross-testing. My team is responsible for roughly 150 enterprise apps of varying scale, platform, age, and quality, ranging from a few disgusting classic ASP apps to monstrosities we pay nearly $1m/yr in licensing fees for. It is neither feasible nor the best use of people's time to keep up with 12wk release cycles. - Security. There are good reasons why not to allow local admin privileges for most users. Chrome is the first browser we've deployed that we've allowed auto-update to remain enabled, and if it didn't provide silent updates that didn't break extensions AND install in user space, we'd never have been able to do that. - Antivirus. I'd have thought you'd know this based on the verbiage in your comment, but apparently not. Enterprise AV doesn't work like consumer AV. An orchestrating server software is installed, at which configurations are defined and from which rule sets are distributed to clients. - Big ERP. As an example, Oracle ERP isn't compatible with every version of Java, and god help you if your users are running Linux and get confused between the official JRE and independent distributions like OpenJDK & Iced Tea. If your apps team has built extensions/interfaces to the ERP that also rely on Java, it's entirely possible or likely that they're dependent on a specific version & patch number, too. I could go on for hours. I don't think anyone -- at least none of my peers or colleagues -- would say rapid browser versioning & automatic releases are bad. Not being able to manage them can be risky. We have recently standardized on Chrome, but have deployed Firefox 8 as a fallback just in case, and our Windows users have IE8 (or 9, in the case of the few running Win7). For both Firefox & Chrome we included IETab in the MSI we distributed, customized with rules based on app compatibility. We also distributed a custom PAC file with proxy rules. Coincidentally, most of the web developers -- even if they prefer Chrome for browsing -- still prefer Firefox for dev & testing due to the superiority of Firebug & a few other add-ons.
      - AndrewDucker 15y ago
        From my understanding there will be a single one-off UAC popup which will allow a service to be installed with higher rights - that service will then carry out installations from that point on, and will be able to do so silently, as it will have the rights to do so.
        gcp 15y ago
        Why is there still a need to deal with UAC? Why does it need admin rights in the first place? Sounds entirely avoidable (see: Chrome).
        AndrewDucker 15y ago
        Chrome avoids it by installing into the User's own folder. Firefox is installed in Program Files, which requires user authorisation. Arguably, this is the correct place to install, as it means that the application is usable by anyone on the PC, rather than having to be installed for each user individually. You can find more information here: http://www.brianbondy.com/blog/id/125/ http://www.brianbondy.com/blog/id/125/
        zobzu 15y ago
        Chrome does a non-standard install and also can be self modified which isn't secure. Chrome could be replaced by a keylogger+chrome by anything running on the system. That's why admin privileges are required for accessing Program Files to begin with. Using a separate updater process is actually the clean way to go, on Windows.
  - AndrewDucker 15y ago
    It already does automatic updates, and work is progressing to make them silent (like Chrome's).
  - ComputerGuru 15y ago
    It does, but it's nowhere near as smooth, and I'm not talking about dialogs and user intervention. Whereas Chrome has a stable extension API, Firefox really breaks at least one very popular plugin withe each "release." So then you get nasty warnings about incompatible plugin versions and whether or not you want to look up a new version of the plugin. Whereas Chrome a) doesn't break plugin APIs very often, even in alpha and beta channels and b) automatically updates plugins anyway.
    - icebraining 15y ago
      Firefox also upgrades plugins automatically, provided they pass a bunch of automated tests. Unfortunately, it seems many don't. The openness of their API is certainly a two edge sword; in one way, it lets developers dig deep in the browser's internals, which means addons can be immensely more powerful than on Chrome; on the other hand, it means they have a dependency on those same internal APIs. They've launched the Jetpack SDK as a stable API for addons that doesn't require browser restarts to install them, but almost no one uses it:|
      - steve-howard 15y ago
        I wonder if there's anything other than momentum holding Jetpack back. I would be interested in trying to get some add-ons ported just for fun. I do agree that the add-ons in Firefox are way more powerful; I like that Adblock on FF can block ads before they're even retrieved (leaving my Hulu experience punctuated by silence rather than noise).
    - masklinn 15y ago
      > Whereas Chrome has a stable extension API, Firefox really breaks at least one very popular plugin withe each "release." It's not really the API which breaks, it's the versioning.
      - gcp 15y ago
        Doesn't matter, the end-user result is still the same: the browser breaks on every upgrade. It's beyond inexcusable that this is still not fixed, and I'm sure its part of the reason the userbase declined further.
- gcp 15y ago
  I can't find any public headcount figures, but their weekly meeting notes often show multiple new hires for many weeks now (unsure about the amount of departures). I'm guessing part of the faster improvement is that they've increased headcount and these people are becoming productive.
  - pbiggar 15y ago
    Mozilla doubled in size over the last year, to nearly 700 people I think.
- ck2 15y ago
  I am more pleased with Firefox8 than I ever was with Firefox3 But I have to use several more extensions to get back some features that were taken out.
  - amackera 15y ago
    Honestly I think this is a good thing.
  - patrickod 15y ago
    While I'm sure it was an annoyance to lose some functionality and have to use plugins I think the move towards a leaner, more efficient version of Firefox is definitely a great move. It'll bring speedier web browsing to the majority of users.
nickik 15y ago
Mhh. LuaJit has quite shown that TraceJit can be awesome for dynamic languages. Sure JS has less potential to be optimized then lua (see in this http://lambda-the-ultimate.org/node/3851 http://lambda-the-ultimate.org/node/3851 LtU thread somewhere and read the rest anyway if your intressted in JITs) but the genarall aprouch could still be used. LuaJit does it by using a very fast interpreter and a tracecompiler. The secret souce seams to be a SSA based bytecode. Im not sure how the Mozilla interpreter works but since its a relice I doute that its a bytecode optimized for interpreting and compilling. If Mozilla would adopt the same method LuaJit uses they would have to reimplment everything from ground up. Witch probebly wouldn't be a smart move buisnesswise. If the language is to hart to interpret one could write a simple first stage method-jit and a trace-jit behind it. Exiting times in JIT-Land spezially for dynamic languages. Lets see who comes out with the best implementation in the long run.
- gcp 15y ago
  The article already explains this, doesn't it? The code had both a Trace-JIT and a Method-JIT [1], but that switching between the two to use the fastest is problematic and that its apparently easier to get the Method-JIT to incorporate more advanced optimization and outperform the Trace-JIT in the end. If Mozilla would adopt the same method LuaJit uses they would have to reimplment everything from ground up. Witch probebly wouldn't be a smart move buisnesswise. I'm not an expert but the existence of "SpiderMonkey" "TraceMonkey" "JeagerMonkey" and "IonMonkey" (which can apparently be disabled independently) seems to suggest they have no problems with that. [1] I presume there is always a fallback interpreter as well.
  - nickik 15y ago
    The method I talked about would work diffrent let me expand a little. I can imagen that jumping between two jits is problematic spezially if there is an interpreter throwen in. The method I talk about would use a simple method jit that generates assembly and the code to enable tracing. This compiler would not optimize anything only get rid of the interpreter overhead. Then the trace jit would jump in if it finds a worthy trace. There would be no switching between the two only from one to the other. In the LtU thread they talk about this too. I don't read anywhere that the method-jit is better in optimizing, i only that the trace-jit dosn't find enought stuff to win. Once you have a good trace you can optimize it like crazy. Mozilla seams to move in this direction, they have thrown out Tracemonky but in the longrun add one again and as far as I know the want to throw out spidermonky too. The diffrence would be that they would have more power in the method jit and less in the trace jit. The reason I said that they would have reimplemented alot is that for the intepreter/simple-jit method and trace-jit to work well you need a nicly designed bytecode and I'm not sure they have one atm (I don't really know). There existing implmentation would have to be reworked to use a new bytecode.
ComputerGuru 15y ago
67,000 lines of C++ is actually not a lot of code. It really depends on _where_ these lines are (i.e. are they in a hot path? How _often_ they are the executed?) and how well written it is. EDIT: I know it's been disabled for months - I'm referring to the original disabling of this code.
- dchest 15y ago
  As said in the second sentence of the linked post, they were disabled even before they were removed.
- stephen_g 15y ago
  It says in the first paragraph that TraceMonkey was actually disabled months ago. So it's says more about keeping the codebase clean then anything about memory or speed of the browser.
- AshleysBrain 15y ago
  Removing code from codebases is actually really great for keeping it maintainable. It really should happen more but I get the feeling in a lot of places code is basically never removed. So IMO removing 67k lines of code is good news for the long-term maintainability of any project! (As long as there's some source code left, heh)
Tloewald 15y ago
"As to the size of plugin-container.exe: that is all flash’s fault. There is literally nothing we can do to fix this other than to kill off flash usage on the web." Interesting comment w.r.t. efforts to shrink Firefox's memory footprint being at the mercy of Flash.
- gcp 15y ago
  I think it's in a separate .exe from firefox.exe specifically for that reason, i.e. so the browser doesn't get blamed (or crashes) when dealing with crap plugins. I'm not sure if Firefox can kill off that process (and reclaim memory) when no plugins are running. The other browsers should have the same problem, right? They have to run Flash somehow.
  - Tloewald 15y ago
    No criticism of Firefox intended, more just one more reason to despise flash.
olov 15y ago
Tracing is no silver-bullet. Mike Pall is.
- azakai 15y ago
  Very true. Mike Pall is truly exceptional. Also worth mentioning is that LuaJIT and JS engines have different constraints. For example, JS engines must be very careful about security, LuaJIT does not. So JS engines need to do more cleanup/initialization for example, to prevent things like heap spray attacks, which LuaJIT does not. Also, JS engines are written to be maintainable by a large team, LuaJIT is really focused entirely on speed.
  - mikemike 15y ago
    LuaJIT is written with security in mind. LuaJIT 2.x had permanent write-protection enabled for the generated machine code in the first release, i.e. before anyone else did so. I do not see how maintainability could somehow have an inverse relation to the engine speed. IMHO the LuaJIT code base is significantly more maintainable than the Mozilla code base. Related: Fate of Unladen Swallow and TraceMonkey predicted about two years ago, in February 2010: http://www.reddit.com/r/programming/comments/azibq/a_rant_about_php_compilers_in_general_and_hiphop/c0k7yfl http://www.reddit.com/r/programming/comments/azibq/a_rant_ab...
    - azakai 15y ago
      Ah, very interesting, thanks for replying! Can you elaborate on what you mean by "permanent write-protection"? Is that to prevent code being overwritten? If so, that is just one possible attack. Does LuaJIT implement techniques to mitigate heap spray attacks and heap inspection problems? JS engines work against that by initializing things like typed arrays to 0, and by overwriting objects when they are free'd. These have a runtime cost though, I'm curious if LuaJIT incurs it as well. Regarding maintainability, your handwritten interpreter in assembly is not something I would expect other people to easily get up to speed on. The JS engine codebases are more approachable IMHO.
deleted 15y ago
[deleted]
- vinhboy 15y ago
  firebug > inspector
  - lean 15y ago
    how so?
- robin_reala 15y ago
  Your Firefox profile is broken. If you do decide to give it another try make sure you delete it and start afresh. A stock Firefox is not sluggish or crashy.
  - lelele 15y ago
    What's the purpose of using Firefox if you lose all your customizations? Just like Emacs, Firefox rules because it's customizable. On my Linux box, Firefox crashes tens of times a day. I've not dumped it yet because it's the only browser which allows me to customize pages' colors in a reliable way.
    - robin_reala 15y ago
      I’m not saying that your customisations are breaking Firefox, I’m saying that something in your profile has gone awry and is causing it to crash. I’ve not used the page colour customisation but it’d be worth trying a stock Firefox then dropping your customisations back in to see if that fixes it. You can create a new profile by following these instructions: http://kb.mozillazine.org/Profile_manager#Linux http://kb.mozillazine.org/Profile_manager#Linux You can also see a list of crash reports from your install by going to about:crashes . These link through to the Mozilla crash log server, which often then links onto the appropriate bug in Bugzilla. You might find that what’s causing the crashes has been fixed in an upcoming release.
    - bzbarsky 15y ago
interlagos 15y ago
On an aside, relating to the performance of these two Firefox technologies, it is interesting that in the battle of the JavaScript engines it is artificial metrics that are driving the game: No one is measuring the number of clocks taken to run the JavaScript on typical pages like Twitter or gmail, or whether the variance is enough to even noticeably matter, but instead we run looping benchmark code entirely unlike anything actually used in practice (SunSpider being the most egregiously invalid test). I would posit, based upon nothing, that in practice JIT systems can be a net negative to the overwhelming majority of run-once JavaScript encountered across the tubes.
funkah 15y ago
TraceMonkey, JaegerMonkey, and IonMonkey. Well, the names are nothing if not consistent, but impossible to keep straight. I think IonMonkey is the new one?
- azakai 15y ago
  TraceMonkey is/was a tracing JIT. JaegerMonkey is a method JIT. IonMonkey is an SSA-optimizing JIT. Type Inference is additional code that analyzes JS both globally and locally for types, and feeds that info into the JITs to make them more effective. Previously Firefox used TraceMonkey, then TraceMonkey+JaegerMonkey, and now JaegerMonkey+Type Inference. The plan is to move to IonMonkey+Type Inference (not sure where JaegerMonkey fits into that).
- cdleary_ 15y ago
  I also did a write up on this called "Mapping the monkeysphere" that you may find helpful: http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/ http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/

211 points by llambda 15y ago

I know people like to complain about the new rapid release cycle, but there's been a definite upswing in the work going on on Mozilla since it started. I wonder if knowing that your code will be on people's desktops in three months rather than two years makes a big difference.

Pheter 15y ago
Does Firefox plan to use the same style of forced updates that Chrome does? As a web developer I am very grateful that Chrome is not only updated regularly but that these updates are forced on the end user. IE10 could be the best browser ever, but unfortunately there will still be people using IE7.
- richbradshaw 15y ago
  It already does I believe, or at least, they are hard to not accept.
- smspence 15y ago
  I believe automatic, silent updates are coming in Firefox 10.
  - eiji 15y ago
    I don't see silent updates in FF10 yet. True silent ones are only possible if you move the install into the Roaming area, otherwise win7 with resonable security settings will ask for confirmation. From what I know, IT-departments don't like that.
    - joelhaasnoot 15y ago
      IT departments need to stop complaining and get their act together. That, and enterprise software firms should stop charging an arm and a leg for updates, and stop making software that will only run in IE (6). If you buy that software, shout at your boss, not at Firefox or Chrome.
    - nl 15y ago
      From what I know, IT-departments don't like that. It's important to note that, yes, it is true that some IT department are reactionary and dislike the new release process, BUT that doesn't mean that are right. There are plenty of analogous automatic update systems which are used every day in IT departments. Virus checkers are the canonical example, but increasingly SAAS applications are the same. Many IT departments are stuck in a 1999 mode of trying to control the exact version of every software they run. Fortunately businesses are wising up - firstly IT tried to tell them they couldn't use iPhone because they "weren't approved". That worked until the CEO demanded one. Now some try and say rapid browser versioning and automatic releases are bad. They'll get over that, too, or otherwise they'll be ignored. (And don't bring up the example of the IE6 websites that must use IE6 forever more. That's a problem to solve, not an excuse for keeping an entire enterprise locked to outdated technology.)
      - eitally 15y ago
        You're just wrong. There are several very good reasons why the 1999 mode is both useful and important, at least for the time being (and the next several years). Here is a brief list: - Cross-testing. My team is responsible for roughly 150 enterprise apps of varying scale, platform, age, and quality, ranging from a few disgusting classic ASP apps to monstrosities we pay nearly $1m/yr in licensing fees for. It is neither feasible nor the best use of people's time to keep up with 12wk release cycles. - Security. There are good reasons why not to allow local admin privileges for most users. Chrome is the first browser we've deployed that we've allowed auto-update to remain enabled, and if it didn't provide silent updates that didn't break extensions AND install in user space, we'd never have been able to do that. - Antivirus. I'd have thought you'd know this based on the verbiage in your comment, but apparently not. Enterprise AV doesn't work like consumer AV. An orchestrating server software is installed, at which configurations are defined and from which rule sets are distributed to clients. - Big ERP. As an example, Oracle ERP isn't compatible with every version of Java, and god help you if your users are running Linux and get confused between the official JRE and independent distributions like OpenJDK & Iced Tea. If your apps team has built extensions/interfaces to the ERP that also rely on Java, it's entirely possible or likely that they're dependent on a specific version & patch number, too. I could go on for hours. I don't think anyone -- at least none of my peers or colleagues -- would say rapid browser versioning & automatic releases are bad. Not being able to manage them can be risky. We have recently standardized on Chrome, but have deployed Firefox 8 as a fallback just in case, and our Windows users have IE8 (or 9, in the case of the few running Win7). For both Firefox & Chrome we included IETab in the MSI we distributed, customized with rules based on app compatibility. We also distributed a custom PAC file with proxy rules. Coincidentally, most of the web developers -- even if they prefer Chrome for browsing -- still prefer Firefox for dev & testing due to the superiority of Firebug & a few other add-ons.
    - AndrewDucker 15y ago
      From my understanding there will be a single one-off UAC popup which will allow a service to be installed with higher rights - that service will then carry out installations from that point on, and will be able to do so silently, as it will have the rights to do so.
      - gcp 15y ago
        Why is there still a need to deal with UAC? Why does it need admin rights in the first place? Sounds entirely avoidable (see: Chrome).
        AndrewDucker 15y ago
        Chrome avoids it by installing into the User's own folder. Firefox is installed in Program Files, which requires user authorisation. Arguably, this is the correct place to install, as it means that the application is usable by anyone on the PC, rather than having to be installed for each user individually. You can find more information here: http://www.brianbondy.com/blog/id/125/ http://www.brianbondy.com/blog/id/125/
        zobzu 15y ago
        Chrome does a non-standard install and also can be self modified which isn't secure. Chrome could be replaced by a keylogger+chrome by anything running on the system. That's why admin privileges are required for accessing Program Files to begin with. Using a separate updater process is actually the clean way to go, on Windows.
- AndrewDucker 15y ago
  It already does automatic updates, and work is progressing to make them silent (like Chrome's).
- ComputerGuru 15y ago
  It does, but it's nowhere near as smooth, and I'm not talking about dialogs and user intervention. Whereas Chrome has a stable extension API, Firefox really breaks at least one very popular plugin withe each "release." So then you get nasty warnings about incompatible plugin versions and whether or not you want to look up a new version of the plugin. Whereas Chrome a) doesn't break plugin APIs very often, even in alpha and beta channels and b) automatically updates plugins anyway.
  - icebraining 15y ago
    Firefox also upgrades plugins automatically, provided they pass a bunch of automated tests. Unfortunately, it seems many don't. The openness of their API is certainly a two edge sword; in one way, it lets developers dig deep in the browser's internals, which means addons can be immensely more powerful than on Chrome; on the other hand, it means they have a dependency on those same internal APIs. They've launched the Jetpack SDK as a stable API for addons that doesn't require browser restarts to install them, but almost no one uses it:|
    - steve-howard 15y ago
      I wonder if there's anything other than momentum holding Jetpack back. I would be interested in trying to get some add-ons ported just for fun. I do agree that the add-ons in Firefox are way more powerful; I like that Adblock on FF can block ads before they're even retrieved (leaving my Hulu experience punctuated by silence rather than noise).
  - masklinn 15y ago
    > Whereas Chrome has a stable extension API, Firefox really breaks at least one very popular plugin withe each "release." It's not really the API which breaks, it's the versioning.
    - gcp 15y ago
      Doesn't matter, the end-user result is still the same: the browser breaks on every upgrade. It's beyond inexcusable that this is still not fixed, and I'm sure its part of the reason the userbase declined further.
gcp 15y ago
I can't find any public headcount figures, but their weekly meeting notes often show multiple new hires for many weeks now (unsure about the amount of departures). I'm guessing part of the faster improvement is that they've increased headcount and these people are becoming productive.
- pbiggar 15y ago
  Mozilla doubled in size over the last year, to nearly 700 people I think.
ck2 15y ago
I am more pleased with Firefox8 than I ever was with Firefox3 But I have to use several more extensions to get back some features that were taken out.
- amackera 15y ago
  Honestly I think this is a good thing.
- patrickod 15y ago
  While I'm sure it was an annoyance to lose some functionality and have to use plugins I think the move towards a leaner, more efficient version of Firefox is definitely a great move. It'll bring speedier web browsing to the majority of users.

nickik 15y ago

Mhh. LuaJit has quite shown that TraceJit can be awesome for dynamic languages. Sure JS has less potential to be optimized then lua (see in this http://lambda-the-ultimate.org/node/3851 http://lambda-the-ultimate.org/node/3851 LtU thread somewhere and read the rest anyway if your intressted in JITs) but the genarall aprouch could still be used. LuaJit does it by using a very fast interpreter and a tracecompiler. The secret souce seams to be a SSA based bytecode. Im not sure how the Mozilla interpreter works but since its a relice I doute that its a bytecode optimized for interpreting and compilling. If Mozilla would adopt the same method LuaJit uses they would have to reimplment everything from ground up. Witch probebly wouldn't be a smart move buisnesswise. If the language is to hart to interpret one could write a simple first stage method-jit and a trace-jit behind it. Exiting times in JIT-Land spezially for dynamic languages. Lets see who comes out with the best implementation in the long run.

gcp 15y ago
The article already explains this, doesn't it? The code had both a Trace-JIT and a Method-JIT [1], but that switching between the two to use the fastest is problematic and that its apparently easier to get the Method-JIT to incorporate more advanced optimization and outperform the Trace-JIT in the end. If Mozilla would adopt the same method LuaJit uses they would have to reimplment everything from ground up. Witch probebly wouldn't be a smart move buisnesswise. I'm not an expert but the existence of "SpiderMonkey" "TraceMonkey" "JeagerMonkey" and "IonMonkey" (which can apparently be disabled independently) seems to suggest they have no problems with that. [1] I presume there is always a fallback interpreter as well.
- nickik 15y ago
  The method I talked about would work diffrent let me expand a little. I can imagen that jumping between two jits is problematic spezially if there is an interpreter throwen in. The method I talk about would use a simple method jit that generates assembly and the code to enable tracing. This compiler would not optimize anything only get rid of the interpreter overhead. Then the trace jit would jump in if it finds a worthy trace. There would be no switching between the two only from one to the other. In the LtU thread they talk about this too. I don't read anywhere that the method-jit is better in optimizing, i only that the trace-jit dosn't find enought stuff to win. Once you have a good trace you can optimize it like crazy. Mozilla seams to move in this direction, they have thrown out Tracemonky but in the longrun add one again and as far as I know the want to throw out spidermonky too. The diffrence would be that they would have more power in the method jit and less in the trace jit. The reason I said that they would have reimplemented alot is that for the intepreter/simple-jit method and trace-jit to work well you need a nicly designed bytecode and I'm not sure they have one atm (I don't really know). There existing implmentation would have to be reworked to use a new bytecode.

ComputerGuru 15y ago

67,000 lines of C++ is actually not a lot of code. It really depends on _where_ these lines are (i.e. are they in a hot path? How _often_ they are the executed?) and how well written it is. EDIT: I know it's been disabled for months - I'm referring to the original disabling of this code.

dchest 15y ago
As said in the second sentence of the linked post, they were disabled even before they were removed.
stephen_g 15y ago
It says in the first paragraph that TraceMonkey was actually disabled months ago. So it's says more about keeping the codebase clean then anything about memory or speed of the browser.
AshleysBrain 15y ago
Removing code from codebases is actually really great for keeping it maintainable. It really should happen more but I get the feeling in a lot of places code is basically never removed. So IMO removing 67k lines of code is good news for the long-term maintainability of any project! (As long as there's some source code left, heh)

Tloewald 15y ago

"As to the size of plugin-container.exe: that is all flash’s fault. There is literally nothing we can do to fix this other than to kill off flash usage on the web." Interesting comment w.r.t. efforts to shrink Firefox's memory footprint being at the mercy of Flash.

gcp 15y ago
I think it's in a separate .exe from firefox.exe specifically for that reason, i.e. so the browser doesn't get blamed (or crashes) when dealing with crap plugins. I'm not sure if Firefox can kill off that process (and reclaim memory) when no plugins are running. The other browsers should have the same problem, right? They have to run Flash somehow.
- Tloewald 15y ago
  No criticism of Firefox intended, more just one more reason to despise flash.

olov 15y ago

Tracing is no silver-bullet. Mike Pall is.

azakai 15y ago
Very true. Mike Pall is truly exceptional. Also worth mentioning is that LuaJIT and JS engines have different constraints. For example, JS engines must be very careful about security, LuaJIT does not. So JS engines need to do more cleanup/initialization for example, to prevent things like heap spray attacks, which LuaJIT does not. Also, JS engines are written to be maintainable by a large team, LuaJIT is really focused entirely on speed.
- mikemike 15y ago
  LuaJIT is written with security in mind. LuaJIT 2.x had permanent write-protection enabled for the generated machine code in the first release, i.e. before anyone else did so. I do not see how maintainability could somehow have an inverse relation to the engine speed. IMHO the LuaJIT code base is significantly more maintainable than the Mozilla code base. Related: Fate of Unladen Swallow and TraceMonkey predicted about two years ago, in February 2010: http://www.reddit.com/r/programming/comments/azibq/a_rant_about_php_compilers_in_general_and_hiphop/c0k7yfl http://www.reddit.com/r/programming/comments/azibq/a_rant_ab...
  - azakai 15y ago
    Ah, very interesting, thanks for replying! Can you elaborate on what you mean by "permanent write-protection"? Is that to prevent code being overwritten? If so, that is just one possible attack. Does LuaJIT implement techniques to mitigate heap spray attacks and heap inspection problems? JS engines work against that by initializing things like typed arrays to 0, and by overwriting objects when they are free'd. These have a runtime cost though, I'm curious if LuaJIT incurs it as well. Regarding maintainability, your handwritten interpreter in assembly is not something I would expect other people to easily get up to speed on. The JS engine codebases are more approachable IMHO.

deleted 15y ago

[deleted]

vinhboy 15y ago
firebug > inspector
- lean 15y ago
  how so?
robin_reala 15y ago
Your Firefox profile is broken. If you do decide to give it another try make sure you delete it and start afresh. A stock Firefox is not sluggish or crashy.
- lelele 15y ago
  What's the purpose of using Firefox if you lose all your customizations? Just like Emacs, Firefox rules because it's customizable. On my Linux box, Firefox crashes tens of times a day. I've not dumped it yet because it's the only browser which allows me to customize pages' colors in a reliable way.
  - robin_reala 15y ago
    I’m not saying that your customisations are breaking Firefox, I’m saying that something in your profile has gone awry and is causing it to crash. I’ve not used the page colour customisation but it’d be worth trying a stock Firefox then dropping your customisations back in to see if that fixes it. You can create a new profile by following these instructions: http://kb.mozillazine.org/Profile_manager#Linux http://kb.mozillazine.org/Profile_manager#Linux You can also see a list of crash reports from your install by going to about:crashes . These link through to the Mozilla crash log server, which often then links onto the appropriate bug in Bugzilla. You might find that what’s causing the crashes has been fixed in an upcoming release.
  - bzbarsky 15y ago

interlagos 15y ago

On an aside, relating to the performance of these two Firefox technologies, it is interesting that in the battle of the JavaScript engines it is artificial metrics that are driving the game: No one is measuring the number of clocks taken to run the JavaScript on typical pages like Twitter or gmail, or whether the variance is enough to even noticeably matter, but instead we run looping benchmark code entirely unlike anything actually used in practice (SunSpider being the most egregiously invalid test). I would posit, based upon nothing, that in practice JIT systems can be a net negative to the overwhelming majority of run-once JavaScript encountered across the tubes.

funkah 15y ago

TraceMonkey, JaegerMonkey, and IonMonkey. Well, the names are nothing if not consistent, but impossible to keep straight. I think IonMonkey is the new one?

azakai 15y ago
TraceMonkey is/was a tracing JIT. JaegerMonkey is a method JIT. IonMonkey is an SSA-optimizing JIT. Type Inference is additional code that analyzes JS both globally and locally for types, and feeds that info into the JITs to make them more effective. Previously Firefox used TraceMonkey, then TraceMonkey+JaegerMonkey, and now JaegerMonkey+Type Inference. The plan is to move to IonMonkey+Type Inference (not sure where JaegerMonkey fits into that).
cdleary_ 15y ago
I also did a write up on this called "Mapping the monkeysphere" that you may find helpful: http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/ http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/