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
Review URL: https://codereview.chromium.org/17072002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Add an %IsParallelSupported() builtin function to make possible to check support of parallel processing from JavaScripts.
- Change the test script that if parallel recompilation is forced on a single core CPU, expect that it won't be recompiled in parallel.
- Change the JSFunction::MarkForParallelRecompilation() to fall back gracefully if parallel recompilation is not supported.
BUG=v8:2733
TEST=mjsunit/manual-parallel-recompile
Review URL: https://codereview.chromium.org/17277002
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15184 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change modifies code produced by BaseLoadStubCompiler::GenerateLoadCallback so that instead of calling AccessorGetter direcly it calls InvokeAccessorGetter which changes VM state and calls the actual callback. This way CPU profiler knows which external callback is being executed in this case. Indirect call happens only if CpuProfiler::is_profiling() is true.
This is exactly same change as r15116 with a build fix for test-api.cc
BUG=244580
TBR=danno@chromium.org
Review URL: https://codereview.chromium.org/16858013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15135 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reverts commit f323d984a73bab345c4eab5c1907552ccfa7ccaa.
Broke compilation on the bots with an error that doesn't occur locally:
CXX(target) /mnt/data/b/build/slave/v8-linux-debug/build/v8/out/Debug/obj.target/cctest/test/cctest/test-bignum-dtoa.o
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = int]’:
../test/cctest/test-api.cc:1129: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = unsigned int]’:
../test/cctest/test-api.cc:1136: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = double]’:
../test/cctest/test-api.cc:1143: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = bool]’:
../test/cctest/test-api.cc:1150: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = void]’:
../test/cctest/test-api.cc:1157: error: insufficient contextual information to determine type
CXX(target) /mnt/data/b/build/slave/v8-linux-debug/build/v8/out/Debug/obj.target/cctest/test/cctest/test-circular-queue.o
BUG=None
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/16838013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15117 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows the deoptimizer to materialize objects (e.g. the arguments
object) while deopting without having a consective stack area holding
the object values. The LEnvironment explicitly tracks locations for
these values and preserves them in the translation.
R=svenpanne@chromium.org
TEST=mjsunit/compiler/inline-arguments
Review URL: https://codereview.chromium.org/16779004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15087 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The current specification has GeneratorFunction() be like Function(),
except that it makes generator instances. This commit implements that
behavior. It also fills in a piece of the implementation where
otherwise calling GeneratorFunction or GeneratorFunctionPrototype would
cause an abort because they have no code.
R=mstarzinger@chromium.org
TEST=mjsunit/harmony/generators-iteration
TEST=mjsunit/harmony/generators-runtime
BUG=v8:2355,v8:2680
Review URL: https://codereview.chromium.org/15218004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15084 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When a generator suspends, it saves its state out to the heap and
unwinds try handlers but doesn't pop anything off the stack. Instead it
relies on no GC happening between the suspend and the return from the
generator. However this was not the case: boxing the result object
could cause GC, which would try to traverse the stack but would
misinterpret words from unwound try handlers as heap objects.
This CL changes to allocate the result objects before the suspend. It
also removes the generators-iteration skip introduced in r15065.
R=mstarzinger@chromium.org
TEST=mjsunit/harmony/generators-iteration
BUG=
Review URL: https://codereview.chromium.org/16801006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15079 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
