Aftermath of Logjam

Last week the logjam attack was disclosed. An attack on TLS which is used in many protocol including including HTTPS, SSH, IPsec, SMTPS … The attack relies on the fact that it is possible to negotiate inferior keys for the Diffie-Hellman key exchange. An nice explanation has been put together by cloudflare

We are currently creating PatrolServer, a webapp that will check servers for potential outdated software and possible exploits. This TLS attack was a nice welcome for us to test our capabilities and what we can expect from such a webapp. We created a small scanner where people could provide and test their website/server.

Since it was our first time, it took quite some time before our scanner was ready. We weren’t prepared and still had to make a small infrastructure for this one-off test and add a little bit of a decent layout. Half a day after the facts we were live and we could redirect people to our tool and hope they would fix their server.

“To measure is to know” — Sir William Thomson

Our first objective on getting people to test their server went smoothly. Over three days we were just short of testing 2000 unique servers. In most cases their own server, but some people also were naughty enough to test corporate servers like google, gmail, banks, yahoo, reddit … We even had somebody out of Toledo (Spain) abusing the system to generate a list of all vulnerable sites. Upon detection he was off course banned. Some ideas came to mind like always returning either vulnerable or not vulnerable or even returning random results. Though we decided to just hide the results. Maybe we can do something alike next time. We also got a request on twitter (twitter.com/patrolserver) to enable SNI hosts. Which we didn’t supported at the time. We want to thanks everybody that used the tool and the suggestions. Always appreciated.

“Those who have the privilege to know have the duty to act.” — Albert Einstein

The second objective, the paramount goal of our little startup, is to get people to fix their servers. The Open Web Application Security Project (OWASP) scored server misconfiguration and not updating servers on the fifth position in their top 10 web application security list. On our tool we saw a lot of servers were outdated. We saw that 30% of our tests returned an affected state.

A week later we reran the list to see how things have progressed and saw only one server that actually fixed the problem afterwards. That is quite low. People know their server has a problem, but they don’t act on it. We assume that is something we will also see in the full webapp. The biggest goal of PatrolServer, after reporting issues with a server, will be to engage people to fix the issues. How is a bigger question. We are still trying to figure that part out. We already have a lot of ideas, but also need to find the right balance between annoying people and being helpful about vulnerabilities. If you got a suggestion please let us know!

Closing remarks: PatrolServer is getting actively developed. The platform to detect outdated software is in place. We already have support for some software, but we still want to increase the list. The frontend has gotten some layout love, which isn’t quite finished yet. In the close future we will probably start a closed or open beta in order to get some early feedback. Anybody wanting to get notified about this milestone and/or anybody wanting to test drive the platform on their server can enter their email address here:
[smlsubform]

Year in review: Spidermonkey in 2014 part 3

In the first two parts I listed the major changes in the Javascript engine of Mozilla Firefox in 2014 and enumerated the major changes that happened starting from Firefox 29 till Firefox 34. In part 3 I will iterate the major changes in the JavaScript engine in the last two releases that were developed in 2014.

If you haven’t read the first parts yet, I would encourage you to do that first.
<- Year in review: Spidermonkey in 2014 part 1
<- Year in review: Spidermonkey in 2014 part 2

Firefox 35

JIT RegExp.prototype.exec and RegExp.prototype.test

When Firefox 32 was released the regular expression engine was replaced with Irregexp. The new engine had just like its predecessor a small jit where regular expressions get compiled to native code. And just like its predecessor the easiest way to embed the regular expression engine is to use C code. Consequently a normal execution of a regular expression looked as following. The js code goes into C code preparing the regular expression engine jit, whereafter the regular expression engine gets called. In this release we eliminated the middle step (the c code) and now jump directly from JS jit to regular expression jit, removing the overhead the c code provided when calling RegExp.prototype.exec or RegExp.prototype.test.

Read more about this in the bug report

GVN + UCE combined

Just like most compilers Ionmonkey has an optimization called Global Value Numbering (GVN). It tries to remove or replace redundant instructions. In our implementation it is also the place where most replaces based on inputs happen, like constant folding, identity removal … After this pass we run Unreachable Code Elimination (UCE), which eliminates branches which are never taken. Optimizations taking place during GVN can improve the efficiency of UCE. More folded instructions can increase how many code that can be found to be dead. On the other hand removed code can again make it possible for GVN to optimize some extra instructions. Before Firefox 35 we only ran both passes once. As a result we sometimes didn’t find the most optimal code. With this release GVN and UCE are now combined, making it possible to have the same optimizations as running GVN and UCE multiple times after each other, but doing so in only one pass.

Learn more about this in an explanatory video

Lazy linking when recompiling code

The compilation of Ion code happens in three phases. First we have the graph creation phase (happens in IonBuilder), afterwards we do all sort of optimizations on that graph, ending with a linking phase, which finishes the compilation. In this sequence only the optimizing part can be done off the main thread. The other two phases block execution of JavaScript code. Lazy linking is about improving the last phase. Currently linking happens eagerly. As soon as a graph is ready we will try to link it. Even if we won’t ever execute that code (again) or if it gets invalidated due to better types. With lazy linking we wait until we want to execute that code before linking.

Read more about this in the bug report.

Compile non-CNG functions

Compile and Go (CNG) functions give extra performance since the caller cannot modify objects on the scope chain between compilation and execution [1]. With this warranty compilers can optimize access to these objects better. Now IonMonkey can only compile such functions. Non-CNG were stuck in the baseline compiler. In Firefox 34 and 35 these limitations were mostly removed. Given our most important class of non-CNG functions are in addons and chrome content. This will give again a nice boost to performance of these.

Read more about this in the bug reports: bug 1064777, bug 1045529 and bug 911570

Firefox 36

Baseline compile generators

Like mentioned in part 1, Firefox 30 saw the introduction of ES6 generators. In that release only supported for the interpreter (our first tier) was added. This was because the initial implementation tried to support this feature touching as little code as possible. But this method also disabled support for higher tiers. Six releases later we are now proud to also have support for generators in our second tier, the baseline compiler and that even before ES6 is released.

Wingo did the beginning of this huge task and has written a blogpost about it.
Read the blogpost about support of compiling generators in Baseline

ES6 Symbols

For the first time in a very long time a new primitive type was added to the engine. This all has to do with the upcoming spec. of ES6 Symbols. Nexto null, undefined, boolean, number and string, symbol is now present on that list. A Symbol is a unique and immutable primitive value. Without going too deep it can enable hiding of properties or fix name clashes between properties. It also can helps with not breaking existing codebases when new property names to the language are introduced. Not immediately something people need to use, but it can open new and maybe better ways to do some things.

Read more about this in the developer reference
Stackoverflow: why bring symbols to JS

Selfhosting String.prototype.substr, String.prototype.substring and String.prototype.slice

In Firefox 20 the selfhosting infrastructure landed. Since that release we can implement JavaScript features in JavaScript itself, instead of writing it in C. During runtime this selfhosted function will just get executed like somebody would have scripted in JavaScript. The major improvement here is that we remove the overhead from calling from JavaScript out to C and back. This gave improvements for e.g. “array.map(function() { /* … */})” since the C step was fully eliminated between calling the function and the function given in the argument. In this release substr, substring and slice are now also selfhosted. For these functions the speedup is mostly because the edge case checks (start is positive and length is smaller than string length) are now done in JavaScript and IonMonkey can reason about them and potentially remove those checks!

Read more about this in the bug report

Year in review: Spidermonkey in 2014 part 2

In the first part of this series I noted that the major changes in Spidermonkey in 2014 were about EcmaScript 6.0 compliance, JavaScript performance and GC improvements. I also enumerated the major changes that happened starting from Firefox 29 till Firefox 31 related to Spidermonkey. If you haven’t read the first part yet, I would encourage you to do that first. In part two I will continue iterating the major changes  from Firefox 32 till Firefox 34.

<- Year in review: Spidermonkey in 2014 part 1

Firefox 32

Recover instructions

During the Firefox 32 release recover instructions were introduced. This adds the possibility to do more aggressive optimizations in IonMonkey. Before we couldn’t eliminate some instructions since the result was needed if we had to switch back to a lower compiler tier (bailout from IonMonkey to Baseline). This new infrastructure makes it possible to recover the needed result by adding instructions to this bailout path. As a result, we still have the needed results to bailout, but don’t have to keep a normally unused instruction in the code stream.

Read more about this change
Read more about this in the bug report

Irregexp

Internally there has been a lot of discussion around the regular expression engine used in Spidermonkey. We used to use yarr, which is the regular expression engine of Webkit. Though there were some issues here. We sometimes got wrong results, there were security issues and yarr hasn’t been updated in a while. As a result we switched to irregexp, the regular expression engine in v8 (the JS engine in Chrome). In the long run this helps by having a more up to date engine, which has jit to jit support and is more actively tested for security issues.

Read more about this in the bug report

Keep Ion code during GC

Another achievement that landed in Firefox 29 was the ability to keep ionmonkey jit code during GC. This required Type  Inference changes. Type information (TI) was always cleared during GC and since ionmonkey code depends on it, the code became invalid and we had to throw the Ion code away. Since a few releases we can release Type information in chunks and since Firefox 32 we keep ionmonkey code that is active on the stack. This result in less bumps in performance during GC, since we don’t lose the Ion code.

Read more about this in the bug report

Generational GC

Already going back to 2011 Generational GC was announced. But it took a lot of work before finally accomplishing this. In Firefox 29 exact rooting landed, which was a prerequisite. Now we finally use a more advanced GC algorithm to collect the memory and this also paves the way for even more advanced GC algorithms. This narrowed the performance gap we had on the Octane benchmark compared to V8, which already had Generational GC.

Read more about this change

Firefox 33

8 bit strings

Since the first Spidermonkey release strings were always stored as a sequence of UTF-16 code units. So every string takes 16 bits per character. This is quite wasteful, since most of the strings don’t need the extended format and the characters actually fit nicely into 8 bits (Latin1 strings). From this release on strings will be stored in this smaller format when possible. The main idea was to decreases memory, but there were also some performance increases for string intensive tasks, since they now only need to operate over half the length.

Read more about this change

Firefox 34

ES6 template strings

ES6 will introduce something called template strings. These template strings are surrounded by backticks ( ` ) and among others will allow to create multi-line strings, which weren’t possible before. Template strings also enable to embed expressions into strings without using concatenation. Support for this feature has been introduced in Firefox 34.

Read more about ES6 template strings.

Copy on write

Some new optimization has been added regarding arrays. Before, when you copied an array, the JavaScript Engine had to copy every single item from the original array to the new array. Which can be an intensive operation for big arrays. In this release this pain has been decreased with the introduction of “Copy on write” arrays. In that case we only copy the content of an array when we start modifying the new array. That way we don’t need to allocate and copy the contents for arrays that get copied but not modified.

Read more about this in the bug report.

Inline global variable

A second optimization was about inlining constant global names and constant name access from singleton scope objects. This optimization will help performance for people having constant variables defined in the global scope. Instead of reading the constants out of memory every time the constant will get embedded into the code, just like if you would have written that constant. So now it is possible to have a “var DEBUG = false” and everywhere you test for DEBUG it will get replaced with ‘false’ and that branch will be removed.

Read more about this in the bug report

SIMD in asm.js

SIMD or Single Instruction Multiple Data makes it possible to execute the same operations on multiple inputs at the same time. Modern cpu’s already have support for this using 128-bits long vectors, but currently we don’t really have access to these speedups in JavaScript. SIMD.js is a proposition to expose this to JavaScript. In Firefox 34 experimental support (only available in Firefox Nightly builds) for these instructions in asm.js code were added. As a result making it possible to create code that can run up to 4x faster (Amdahl’s law) using SIMD. Now work is underway to fully optimize SIMD.js in all Ion-compiled JS. When this work is complete, and assuming continued progress in the standards committee, SIMD.js will be released to all Firefox users in a future version.

Read more about this change
Read more about this in the bug report
View the SIMD.js demos

Update: The next post in this series has been published:
Read part 3 of ‘Year in review: spidermonkey in 2014′ ->

Year in review: Spidermonkey in 2014 part 1

Spidermonkey, the JavaScript engine used in Mozilla Firefox, has undergone big changes in 2014. Just like I did last year I’ll go over the major changes that landed throughout the year. Though this time I’ll split the post into a series of three or four posts. This will allow me to explain the changes a bit more in depth and also keep the posts lighter.

Looking back at 2014 most changes that happened were to improve to the Garbage collection (GC) algorithm, improve our second (Baseline) and third tier compiler (IonMonkey) and implement the EcmaScript 6 (ES6) specification. After months of preparation 2014 was the year for our GC team. We finally came to a state where we improved the Garbage Collection algorithm dramatically.  We also still kept looking to the Octane 2.0 benchmark while also other benchmarks started to get on our examination table more often (BrowserMark, jsbench, dromaeo …). Throughout the year we achieved again a 40% improvement to our Octane score and Browsermark 2.1 improved with 5%, showing the huge effort of everybody involved. Nexto performance improvements we also increased our efforts implementing the ES6 standard. While the standard isn’t released yet, it will get released soon and we want to support most things before that happens.

In this first part I will look at the first three releases that were developed in 2014: Firefox 29 to Firefox 31.

Firefox 29 a.k.a Australis

ARM simulator

Our JavaScript engine is tested quite elaborately on desktop machines (i686 and x86_64 chipset), but less extensively on phones (ARM chipset). Most developers don’t have spare systems running these chips and if they have it is quite hard to set up a testing environment. To improve the situation the ARM simulator of Chrome has been ported to Mozilla. This makes it possible to test, run or debug the biggest and most error prone part of the JavaScript engine (JIT code) on a regular desktop by simulating the ARM instructions. As a result phones should now experience an even more stable JavaScript engine.

Read more about this in the bug report.

Recompile without invalidation

Our highest and fastest tier to run JavaScript code, IonMonkey, was not able to recompile (Ion) code for a JS function while the old Ion code was still present. One had to first throw the old Ion code away, before starting a new IonMonkey compilation for that particular JS function. This was mostly not an issue since recompilation mostly happens when the old Ion code is not correct anymore (E.g. when we observed a new type). For a few cases this was not optimal. Therefore since this release we can recompile a JS function while keeping the old Ion code, until the compilation is finished. The benefits are twofold here. Recompiling a function with an entry at a loop nexto the function entry (OSR) is now less expensive. Secondly this might brings us closer to “Optimization levels” where we want to recompile a JS function with more optimizations, taking longer to compile, and in the meantime run the current old ion code.

Read more about this in the bug report.

EcmaScript 6: Promises

In Firefox 29 ES6 Promises were also enabled by default. Though this is not really the work of the Spidermonkey team, but from the DOM team. Firefox is already using this improvement to the Javascript language, proposed for Harmony (ECMAScript 6) in the frontend extensively and now it was deemed that the specification about Promises wouldn’t change much anymore, making it safe to release on the web.

Read more about Promises.

Exact Stack Rooting

Most higher level languages, just like JavaScript, provide automatic memory management (Garbage collection). This removes the need for developers to free resources themself when they are not needed anymore. (I.e. when they are dead). Our current Garbage collection (GC) algorithm was approximate as it didn’t know exactly which objects were alive, so it had to be conservative. Exact stack rooting was all about changing that to make sure we now exactly which objects are live. This brings some overhead since we now must keep track of every object using a container (rooting), but it also is the most important thing needed before we can start experimenting with more advanced GC schemas like Generational GC and Compacting GC.

Read more about this in the bug report.

Firefox 30

EcmaScript 6: Generators

Basic support of ES6 generators has landed. This new feature adds the support of generator functions and the yield statement and got many people excited. Normally a function runs to completion and returns the result. This is different for generators. Such a function will stop at a yield instruction and upon next execution go further at that yield till the next yield or termination of that function. In this release the support for the Interpreter, our lowest tier, has landed.

Read more about Generators.

Improve type information at branches

JavaScript is a weakly typed or even untyped language. So every instructions has to work with every type. In order to specialize an instruction and make it faster the instructions get annotated with observed types (Type Inference). This works mostly fine, except at branches. It happens a lot at branches that a variable gets tested for being not null and undefined or having a specific type. This information gets lost and we keep using the full type information of that variable in the succeeding code. With this release an infrastructure has been added to reason about these branches in our highest optimization tier, IonMonkey and decrease the types accordingly.

Read more about this in the bug report.

Enable IonMonkey for chrome scripts by default.

IonMonkey was introduced in Firefox 18, more than a year ago, and it has been enabled  by default for quite some time for normal scripts. But it wasn’t enabled for Firefox its own UI and addons (chrome content). Firefox only used the interpreter and baseline in that case. Since this release IonMonkey and TI sort of graduated and TI and IonMonkey for chrome scripts is now enabled by default. A huge win for addons, since they now can get the full JavaScript performance potential of IonMonkey.

Read more about this in the bug report.

Firefox 31

EcmaScript 6: more math methods

ES6 proposes a lot of new Math methods like Math.sign, Math.log2, Math.imul, Math.trunc, Math.cosh, Math.hypot … Most things were already possible to do in JS with some extra code, but now there are functions standardized, making it easier to perform such operations.

Faster ES6 arrow functions

This release also brought performance improvements to the arrow function introduced by ES6. Using arrow functions should now have a similar performance as normal functions, which means an improvement of up to 64 times. This is important since having bad performance for new ES6 features will also decrease the uptake of these new features and apparently our frontend Firefox developers already use this new feature a lot.

Read more about this.

Backtracking register allocator

Just like a regular compiler IonMonkey needs to fit the used variables into a limited set of registers. This is done using a register allocator.  IonMonkey has the ability to run with different register allocators. It uses by default LSRA, but also acquired a backtracking register allocator. This new allocator, based on the new register allocator used in LLVM 3.0, should be faster and improve the allocated registers. For octane-zlib this was an improvement of 21%. In this release this new allocator is enabled by default for asm.js code. Pending some bugs and performance issues on regular code, it will also get enabled by default in normal IonMonkey code in 2015.

Read more about the LLVM 3.0 register allocator.
Read more about this in the bug report.

Update: The next post in this series has been published:
Read part 2 of ‘Year in review: spidermonkey in 2014’ ->

Mozilla Firefox JS engine Januari 2012

There are again a lot of improvements in the JavaScript engine in Mozilla Firefox. Here I will list the speed improvements and regressions happened in the month Januari. This time with three benchmarks. They are know as sunspider (a popular benchmark released by WebKit), V8 (released by google) and jslinux (a pc emulator running linux). The improvements will eventually come into Firefox 12 together with the improvements of the last week of December.

Current JS engine (Jaegermonkey + Type Interference)

Benchmark   December 31st   Januari 26th
jslinux      5306.0 ms         4596.0 ms   improvement of 15%
V8           7196.6            6953.4      regression in score of 3.5%
sunspider    165.87 ms        167.445 ms   regression of 0.1%

The biggest difference is the huge improvement on the jslinux benchmark. This is like Bhackett promised due to  landing of bug 706914. This compiles scripts in smaller chunks. This way the compilation time gets decreased.

Detailed overview
Note this list just gives an indication what revisions/bugs potentially increased/decreased performance. It could be that I’ve listed bugs that actually don’t give the listed speed-up and there could be revisions that have a huge influence on the speed, but that I failed to list here.

be81e5f7850f – Bug 714218 – Specialize some get* implementations to do property-type-specific handling, with their getGeneric forwarding to the appropriate specific implementation.
sunspider: regression of 0.8%

db8ea6327311 – Bug 607692 – Inline parseInt(, <0|10>) in JM.
sunspider: improvement of 0.5%

23f3b97f655a – Bug 710163: (part 2) fix EXT_context_loss semantics.
sunspider: regression of 0.4%

faf5f8842fec – Bug 703157 – Don’t modify dictionary shapes in place.
sunspider: improvement of 0.5%

78d17e22a223 – Bug 712714 – Remove JOF_CALLOP.
sunspider: regression of 0.6%

e12b877ae637 – Convert a couple always-true appends to infallibleAppend, since that’s what they should have been using
sunspider: improvement of 1%

d0c192e5bd41 – Bug 706914 – Compile large scripts in chunks.
jslinux: improvement of 17.4%
Huge improvement and indeed fixes the regression introduced last month by compiling switch and try blocks.

96a9dffede07 – Bug 717494 – Pass scope chain explicitly to FindProperty
jslinux: improvement of 0.7%

a85cf7f0d235 – Bug 716512 – make sure that gcparam in shell cannot set MAX_GC_BYTES to a value les than the current GC_BYTES.
V8: improvement of 0.8%

7ab4f1ebc7cc – Backout 54cd89b0f1fa (Bug 712714 backout). Talos will probably report fake regressions for this patch, do not back out for this reason.
V8: regression of 2.5%
Note: Like the commit message already states, this could be a fake regression. But I’m not sure. Every timing I do, shows this is a regression …

Mozilla Firefox JS engine December 2011

In this post I want to iterate over the performance improvements and regressions of the javascript engine in Mozilla Firefox. I will do this by building the cutting edge JS shell of Mozilla. (I use the branch mozilla-inbound). The improvements will not be visible in Firefox immediatly. The improvements that happened before December 23th will go in Firefox 11. The rest will go into Firefox 12.

Current JS engine (Jaegermonkey + Type Interference)

Currently the JavaScript Engine in Firefox uses JaegerMonkey and Type Interference. While JaegerMonkey is relatively old, Type Interference is rather new. Type Interference got enabled only in the newest version (FF 9).

Benchmark    December 1st    December 31st
jslinux         5298.0 ms    5476.5 ms     regression of 180 ms
V8              6811.7       7113.4        improvement in score of 300

One of the regressions I found was the following one:
eaac85c4c05f – Bug 704387: Generate SSA information for scripts containing switch and try blocks
regression of 130ms on jslinux
This increases the compilation time of scripts, with the possibility of creating faster code. In case of jslinux the gained run time doesn’t outweight the extra compilation time and therefor runs slower. Bhackett informed me that the increased compilation time will get lowered with help of bug 706914.