Right now we only run our js tests under -m -j, or maybe -m -j -p (for jsreftest). It seems like to actually cover all the cases that can get hit in the wild, due to the interaction of profiling, blacklisting, side exits, etc, we need to test the following configurations (expressed as shell flags): pure interp -m -m -d -j -m -j -j -p -m -j -p
Does -j -p make sense? Seems like the heuristics underlying -p assume the method JIT is the baseline; I imagine the heuristics would be different if the interpreter is the baseline. Perhaps -p should cause an error if it occurs with both -j and -m?
(In reply to comment #1) > Does -j -p make sense? Seems like the heuristics underlying -p assume the > method JIT is the baseline; I imagine the heuristics would be different if the > interpreter is the baseline. Perhaps -p should cause an error if it occurs > with both -j and -m? Right, -j -p doesn't make sense if your goal is to maximize performance. It's more for testing. Most of the time, we call the profiler from the methodjit. But occasionally the profiler needs to be called from the interpreter. (This happens if we're waiting to get to a methodjit safepoint.) This happens infrequently, so it's nice to be able to test it by running with -j -p, since that causes it to happen much more often. I guess there is a danger that a user might disable the methodjit and forget to disable the profiler. Maybe we could somehow enable -j -p in the shell but not in the browser? I don't know how to do this, though.
See also bug 609413.
You need to log in before you can comment on or make changes to this bug.