
MemShrink progress report, week 23 - llambda
http://blog.mozilla.com/nnethercote/2011/11/23/memshrink-progress-report-week-23/
======
AndrewDucker
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
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.

~~~
ComputerGuru
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.

~~~
masklinn
> 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
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.

~~~
bryanlarsen
I use a good number of extensions, and the upgrade from 7 to 8 went cleanly. I
think they've started to get a handle on it.

------
nickik
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> 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.

~~~
someone13
Part of the reason is also that Mike Pall is actually a hyper-advanced cyborg
from the future.

In case you're not sure what I'm talking about, read through the LuaJIT source
code at some point. It's a thing of beauty - he's handcrafted assembly to make
everything run as fast as possible, on all of x86, x64, PowerPC and now ARM.

~~~
olov
Yes.

"LuaJIT 2.0 intellectual property disclosure and research opportunities"
<[http://article.gmane.org/gmane.comp.lang.lua.general/58908&#...](http://article.gmane.org/gmane.comp.lang.lua.general/58908>);
is further proof to that.

Rumor has it that Mike Pall is actually a collective pseudonym used by an army
of cycle counting language expert cyborgs (from the future).

------
Tloewald
"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
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
No criticism of Firefox intended, more just one more reason to despise flash.

------
olov
Tracing is no silver-bullet. Mike Pall is.

~~~
azakai
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
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_ab...](http://www.reddit.com/r/programming/comments/azibq/a_rant_about_php_compilers_in_general_and_hiphop/c0k7yfl)

~~~
azakai
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.

------
ComputerGuru
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.

~~~
stephen_g
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.

------
interlagos
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
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
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).

