MIPS: Allow timeout for TerminateMultipleV8ThreadsDefaultIsolate.

MIPS: Allow timeout for TerminateMultipleV8ThreadsDefaultIsolate.

test-thread-termination/TerminateMultipleV8ThreadsDefaultIsolate
times out on the MIPS simulator.

Allow the timeouts until this is fixed.

BUG=v8:2657
R=jkummerow@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=15063

[Paul Lind, 2013-06-11 03:02:26]

Jakob, Danno, PTAL, another one outside of mips dir.

[Jakob Kummerow, 2013-06-11 09:46:58]

I'm not opposed to landing this (so you hereby have a formal LGTM), but I would
very much like to see a real fix. As the bug notes, the slowness of this test is
not MIPS- or simulator-specific at all.

[kisg, 2013-06-11 09:56:46]

On 2013/06/11 09:46:58, Jakob wrote:
> I'm not opposed to landing this (so you hereby have a formal LGTM), but I
would
> very much like to see a real fix. As the bug notes, the slowness of this test
is
> not MIPS- or simulator-specific at all.

We are working on a real fix (although at a lower priority when compared to the
daily ports and bug fixes). Were you able to reproduce this issue on your own
systems with ARM simulator or even regular x86 builds? It looks like the problem
is triggered, when all other processes are handled by other cores, and only the
2 V8 JS threads are switching back and forth on the same core. 

An interesting question is (that we are currently investigating) whether this
can happen on a multi-core MIPS (or ARM) system, and could this issue happen
under real workloads (e.g. inside a real browser or Node.js application).

We would like to get this patch in only as a temporary measure, because this bug
gets triggered a lot on our build machine(s).

[Jakob Kummerow, 2013-06-11 10:04:36]

On 2013/06/11 09:56:46, kisg wrote:
> We are working on a real fix (although at a lower priority when compared to
the
> daily ports and bug fixes). Were you able to reproduce this issue on your own
> systems with ARM simulator or even regular x86 builds?

Both ia32 and x64 builds hit this (on a multi-core workstation). Sometimes the
test finishes in less than a second, sometimes it gets killed as timeout after
60 seconds. Anything between happens as well. I can confirm that generating lots
of CPU load seems to make it finish faster.

> It looks like the problem
> is triggered, when all other processes are handled by other cores, and only
the
> 2 V8 JS threads are switching back and forth on the same core. 
> 
> An interesting question is (that we are currently investigating) whether this
> can happen on a multi-core MIPS (or ARM) system, 

Since it happens on multi-core x86 systems, probably yes.

> and could this issue happen
> under real workloads (e.g. inside a real browser or Node.js application).

That would indeed be very interesting to know. 

> We would like to get this patch in only as a temporary measure, because this
bug
> gets triggered a lot on our build machine(s).

Sure, that's fine, and it's why I LGTM'ed it.

[Paul Lind, 2013-06-11 14:31:50]

Committed patchset #1 manually as r15063 (presubmit successful).