612340 - Need to run js tests in various jit combinations

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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

Comment 1

[Nicholas Nethercote [inactive]]

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?

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(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.

Comment 3

[Paul Biggar]

See also bug 609413.

Comment 4

[André Bargull [:anba]]

Nowadays --tbpl should test enough different compiler configurations, therefore marking as WFM.