Firefox 23 goes boom, Baseline takes off

Mozilla is pushing out Firefox 23.0.1. This fixes several bugs in 23 specifically and does not affect us, so there will be no chemspill (the issues fixed are not relevant to 22).

I'm not happy with some of Mozilla's choices for 23. The biggest one that sticks in people's craws is removing the "Enable JavaScript" checkbox. Yes, some dolts will uncheck that, and then ask where the cute kitty videos went to and why their AOLmail won't work, but it's also handy for systems surfing specific websites that don't need scripting (NoScript isn't getting any smaller these days). Also, the mixed security content blocking is messing up a handful of sites, you can't hide the tab bar anymore even if there's only one tab (though in fairness this would probably hose Australis), and it is no longer possible to have separate search engines for the address bar and the search box. You haven't noticed this yet, because 22 still does things the old way.

Mind you, Mozilla does have some not-bad reasons for removing these options (or at least for some of them). I didn't say they were good, necessarily, but they are not-bad; a case can be made. That said, it's cheesing off a lot of users. Sometimes the right change never has the right time, even if it has all the right reasons. Long story short, I am strongly considering keeping the JavaScript checkbox at least in 24, and then we can think about whether this is a change we want to drag along once 24 lifts off. How many of you use that checkbox? Speak!

Back on the development side, PowerPC BaselineCompiler's first script has opened the floodgates (I almost typed "floodgaps"), as predicted, because to get that first simple script to run required a lot of machinery to be online and operational: we have to have an assembler, we have to be able to emit instructions, we have to be able to link branches and calls, and we have to be able to move things around in memory and keep everything in sync. Now that this underlying machinery is tested and mostly proven, the complexity of the code generation can ramp up fast because much smaller changes have much bigger effects. With some tweaks, we've been able to run since Thursday all of the following:

• var i=0
• var i=2; print(i);
• print("hello world!\n");
• var i=2;i=i+3;print(i);
• var i=2;i=i+3;if(i==5)print("five");else print("not five");
• function f(x) { print("hello world"); } f(); f();
• function f(x) { print("hello world"); } f(f());
• function f(x) { print(x); return x; } f(f("hello world"));
• var i;for(i=0;i<5;i++){print("loop"); } print(i);
• var i,j=0;for(i=0;i<5;i++){ j+=i; } print(j);

This is getting very close to phase 3, where the basic functionality is declared "working." I still have to test the rest of the integer math and string packages, as well as floating point operations, recursion and on-stack compilation. Much of this is in cross-platform code, but a very nice thing about BaselineCompiler is that the inline caching code is completely under our control. Inline caches are an important component of just-in-time compilation of dynamic languages like JavaScript, because they allow type specialization of sections of code ("oh, this looks like an integer, so I can make certain optimizeable assumptions about this, assuming it's an integer") that can be built on the fly. I'm pretty proud of some of the optimizations this makes possible. I still don't see the speed being much better than 70-75% that of methodjit, let alone faster, but it should be good enough.

Once we get to this point, I'm going to drop a "save point" for the interested, get the test suite to pass, and then attack the rest of Firefox 24. It's going to be tight for September, but we'll try our hardest.