Fix flaky parallel recompilation test.

Fix flaky parallel recompilation test.

On very rare circumstances parallel recompilation would install
the optimized method earlier than expected and the test would fail.

BUG=
R=yangguo@chromium.org

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

[Yang, 2013-09-25 08:22:04]

On 2013/09/25 08:21:25, oliv wrote:

LGTM.

[oliv, 2013-09-25 08:23:22]

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

[Sven Panne, 2013-10-14 09:56:15]

I think we should reconsider the whole test, and especially this CL. With a
running time of more than 8 seconds on a HP 620 it is by far the longest running
test in release mode. Note that it only takes 24 seconds for all
ia32.release.check with -j32. Funnily enough, we take *less* time in debug mode,
no clue why:

-------------------------------------------------------------------------------------------
svenpanne@svenpanne[master]:~/v8$ tools/run-tests.py --outdir=out --arch=ia32
--time mjsunit/regress/regress-embedded-cons-string
>>> running presubmit tests
Running C++ lint check...
No changes in files detected. Skipping cpplint check.
Running copyright header, trailing whitespaces and two empty lines between
declarations check...
Total violating files: 0
>>> Running tests for ia32.release
No connection to distribution server; running tests locally.
[00:08|% 100|+   3|-   0]: Done                                         

--- Total time: 00:08.644 ---
   1 (00:08.625) mjsunit/regress/regress-embedded-cons-string
   2 (00:02.715) mjsunit/regress/regress-embedded-cons-string
   3 (00:00.812) mjsunit/regress/regress-embedded-cons-string
>>> Running tests for ia32.debug
No connection to distribution server; running tests locally.
[00:03|% 100|+   3|-   0]: Done                                         

--- Total time: 00:03.840 ---
   1 (00:03.816) mjsunit/regress/regress-embedded-cons-string
   2 (00:03.216) mjsunit/regress/regress-embedded-cons-string
   3 (00:01.412) mjsunit/regress/regress-embedded-cons-string
-------------------------------------------------------------------------------------------

Without this CL, the running times are cut by half, but even 4 seconds are *far*
too long. Unit tests should really run far below 1 second.

[Jakob Kummerow, 2013-10-14 11:46:38]

+1 to what Sven said. 3*600ms of scheduled delay time per run (and five times
that with --stress-opt) is not something I like to see in a Release mode test. I
guess Debug is faster because it only does two stress runs.

I have two suggestions for improvements:
- turn this into a cctest where you can trigger just a scavenge instead of a
full GC.
- implement a way to programmatically control the completion time of parallel
recompilation jobs without hard-coded delays
(%FinishConcurrentRecompilationJobNow() or something)

[Yang, 2013-10-14 13:36:12]

On 2013/10/14 11:46:38, Jakob wrote:
> +1 to what Sven said. 3*600ms of scheduled delay time per run (and five times
> that with --stress-opt) is not something I like to see in a Release mode test.
I
> guess Debug is faster because it only does two stress runs.
> 
> I have two suggestions for improvements:
> - turn this into a cctest where you can trigger just a scavenge instead of a
> full GC.
> - implement a way to programmatically control the completion time of parallel
> recompilation jobs without hard-coded delays
> (%FinishConcurrentRecompilationJobNow() or something)

Follow-up CL: https://codereview.chromium.org/26758003/