The jemalloc experiment, once again, runs aground

There's an unacceptable memory leak going on in the jemalloc build which balloons total memory usage on my G5 by about 500MB overnight while idle, and in the morning garbage collection cripples trying to browse with it. The baseline browser has a mild bump overnight, so there may be other leaks going on, but it does not suffer the same issue and browses normally. I don't know what's going on here, but this is a showstopper for jemalloc and neither 22.1 or 24 will have it enabled until this is better understood. It's a shame since it helped on some known troublesome sites, but it's once again a bridge too far and while you're welcome to continue using it the patches are going back in mothballs until I have more time to understand the phenomenon.

While I was trying to analyze the problem, I did notice that we wait a long time to do garbage collection. Mozilla themselves thought this was a problem on slow systems and FirefoxOS in fact garbage collects at a threshold an order of magnitude less than regular Firefox. Since we're closer in spec to FirefoxOS devices, now we do too. It does seem to cut back on some of the random pauses and stutters after the browser has run for awhile, and it will be in 22.1 final even though it did not help with jemalloc. That said, the experience was valuable in that it looks like issue 231 needs to be enabled for 10.5 as well.

BaselineCompiler/Firefox 24 update: most branches and calls seem to be fixed and the generated code now gets far enough to try to call into the JavaScript virtual machine. Near as I can tell from the generated output, unlike methodjit (JaegerMonkey) in 10 through 22, BC emits calls into the JS VM for individual JSOps instead of generating code for those ops (which is now what Ion does). This is slower to run but faster to compile, not unlike some old 8-bit BASIC compilers that instead of generating actual machine code just pre-interpreted the BASIC into a string of calls into the interpreter, removing the parsing overhead. Getting those calls working should speed completion significantly. It does do a little more in that arithmetic options are directly compiled, though, so we'll deal with those later. Right now I just want to compile this: js --baseline-eager --no-ti --no-ion -e 'var i=0' ... and we'll grow from there.

Incidentally, this required me doing bug fixes to Apple gdb to handle frames better. I'll make our hacked gdb-768 available a little later (it's the Xcode 3.0 debugger built for 10.4 with additional patches).