Issue 113 increases our stack to 1GB, which backs the stack pointer all the way
up to 0xf0000000. Unless there are other tricks, this is the maximum we can go
in 32-bit mode, and a 64-bit TenFourFox is not an option. It is better than
crashing on some sites, but systems with less than 1GB of RAM will thrash like
mad. We probably can't avoid this.
Tracejit will be disabled in Fx10 (though we may or may not reenable it). It
will definitely be gone in Fx11 and there will only be methodjit. Methodjit
will definitely change the properties of how we use the stack. It is not at all
clear if it will make it better or worse. We are still required to abide by the
PPC ABI, which means big fat stack frames.
We cannot a priori determine sites that will worst-case the stack, because a
single recursive function that calls itself over and over will do it, and we
can't detect this at JIT time.
Ideas Chris proposed:
- Blacklist. Well, we have one available, it's called NoScript :) It won't
affect legit sites, but will require trial, error and probably a lot of crashes
to construct.
- Use the dom script timeout or a similar construct. This will abort the
tracer, which will slow the site down but will clean the stack up. It may also
affect legitimate sites, but it has the advantage of "just working." We also
need to find a magical value that correlates to stack abuse, and this will vary
with the speed of the system in question.
We can't realistically do this until we have determined the status of the
methodjit (issue 96). If methodjit is go, which has a decent chance, then we
need to work with that and determine the stack usage characteristics before
going forward with this. If not, then we need to consider the above ideas and
do a lot of testing. If we don't do methodjit, then we will essentially be
dropping source parity, so we could be free to implement our own NoScript like
we do in Classilla.
Original issue reported on code.google.com by
classi...@floodgap.comon 1 Dec 2011 at 2:35