Introduce THREADED_PROFILED_TEST macro

Introduce THREADED_PROFILED_TEST macro

A bunch of tests in test-api.cc need to be executed two times: with CPU profiler on and off to check different code paths. There are only two such tests at the moment but I'm going to add more and having this logic duplicated in all these tests look awkward. The tests are executed as part of Threading* tests and there is no much sense in running CPU profiler in that case. This change addresses both problems by introducing THREADED_PROFILED_TEST macro which mosly resembles THREADED_TEST except that when such test is executed as a standalone test (not part of a test-api/Threading*) it will first run the test normally and the start CPU profiler and run the test again.

BUG=244580
R=svenpanne@chromium.org

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

[dcarney, 2013-06-14 17:35:45]

this seems reasonable, but so would a simple profile scope or something of that
nature. I guess it depends how many such tests need to exist and how spread out
they are.  Ultimately Sven and Michael need to decide

[yurys, 2013-06-14 20:21:30]

On 2013/06/14 17:35:45, dcarney wrote:
> this seems reasonable, but so would a simple profile scope or something of
that
> nature. I guess it depends how many such tests need to exist and how spread
out
> they are.  Ultimately Sven and Michael need to decide

I think there are going to be enough such tests to justify adding the macro, see
https://chromiumcodereview.appspot.com/17059005/

[yurys, 2013-06-15 06:31:55]

On 2013/06/14 20:21:30, Yury Semikhatsky wrote:
> On 2013/06/14 17:35:45, dcarney wrote:
> > this seems reasonable, but so would a simple profile scope or something of
> that
> > nature. I guess it depends how many such tests need to exist and how spread
> out
> > they are.  Ultimately Sven and Michael need to decide
> 
> I think there are going to be enough such tests to justify adding the macro,
see
> https://chromiumcodereview.appspot.com/17059005/

It just occured to me that and alternative solution would be to define "void
RunWithProfiler(void (*original_test)())" in test-api.cc and then for 
THREADED_TEST(FunctionTemplate) {..}
add
TEST(FunctionTemplateWithProfiler) {
  RunWithProfiler(TestFunctionTemplate);
}
To save some typing this still can be declared using a THREADED_PROFILED_TEST
macro defined in test-api.cc

Does it sound like a better approach?

[yurys, 2013-06-17 10:24:05]

On 2013/06/15 06:31:55, Yury Semikhatsky wrote:
> On 2013/06/14 20:21:30, Yury Semikhatsky wrote:
> > On 2013/06/14 17:35:45, dcarney wrote:
> > > this seems reasonable, but so would a simple profile scope or something of
> > that
> > > nature. I guess it depends how many such tests need to exist and how
spread
> > out
> > > they are.  Ultimately Sven and Michael need to decide
> > 
> > I think there are going to be enough such tests to justify adding the macro,
> see
> > https://chromiumcodereview.appspot.com/17059005/
> 
> It just occured to me that and alternative solution would be to define "void
> RunWithProfiler(void (*original_test)())" in test-api.cc and then for 
> THREADED_TEST(FunctionTemplate) {..}
> add
> TEST(FunctionTemplateWithProfiler) {
>   RunWithProfiler(TestFunctionTemplate);
> }
> To save some typing this still can be declared using a THREADED_PROFILED_TEST
> macro defined in test-api.cc
> 
> Does it sound like a better approach?

Moved THREADED_PROFILED_TEST macro definition into test-api.cc, now the change
looks better. Please take a look.

[Sven Panne, 2013-06-17 12:22:19]

lgtm

[yurys, 2013-06-20 06:47:17]

Committed patchset #2 manually as r15220 (presubmit successful).