I tried to limit the use of v8::Isolate::GetCurrent() and v8::internal::Isolate::Current() as much as possible, but sometimes this would have involved restructuring tests quite a bit, which is better left for a separate CL.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12716010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13953 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Note that leaving out the Isolate parameter previously had a very special
meaning, namely "use the *default* Isolate", i.e. the one magically created at
program initialization time. All other API entries use the meaning "current
Isolate", which is different in a multi-threaded setting and confusing.
Temporarily disabled deprecations until Chrome is ready.
BUG=v8:2487
Review URL: https://codereview.chromium.org/11970009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13419 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
common.gypi now contains global target defaults and is included by all .gyp files;
standalone.gypi contains definitions for stand-alone v8 builds.
This fixes d8 for the ARM simulator.
TEST=compiles and tests pass on all platforms
Review URL: http://codereview.chromium.org/7740020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9019 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Thread class was receiving an isolate parameter by default.
This approact violates the assumption that only VM threads
can have an associated isolate, and can lead to troubles,
because accessing the same isolate from different threads
leads to race conditions.
This was found by investigating mysterious failures of the
CPU profiler layout test on Linux Chromium. As almost all
threads were associated with some isolate, the sampler was
trying to sample them.
As a side effect, we have also fixed the DebuggerAgent test.
Thanks to Vitaly for help in fixing isolates handling!
R=vitalyr@chromium.org
BUG=none
TEST=none
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8259 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is for mobile platforms where application footprint size is
important. To avoid including compression libraries into V8, we assume
that the host machine have them (true for Linux), and rely on embedder
to provide decompressed data.
Currently, only snapshot data can be comressed. It is also possible to
compress libraries sources, but it is more involved and will be
addressed in another CL.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/6901090
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7724 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix the shell to not use functions from the v8::internal namespace when building with V8 in a shared library.
Remove the v8_preparser library. The dependencies for this target needs to be resolved after isolates have landed.
Review URL: http://codereview.chromium.org/6696067
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7337 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Ensure that there is always enough bytes between consequtive calls in optimized code to write a call instruction at the return points without overlapping.
Add a call to deoptimize all functions after running tests with --stress-opt. This will catch some issues with functions which cannot be forcefully deoptimized. Some of the tests failed on ARM with that change without the rest of the changes in this change.
Review URL: http://codereview.chromium.org/6661022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7132 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In some circumstances, try/finally block can actually catch the exception:
function f() {
try {
throw 42;
} finally {
return 0;
}
}
Therefore when propagating exception to v8::TryCatch, we must be sure
there is no try/finally blocks as well.
When bulding the messages we should be more conservative and expect that
any v8::TryCatch with no JS try/catch in between can potentionally
be the right exception handler.
Plus various minor refactorings.
BUG=1147
TEST=cctest/test-api/TryCatchAndFinallyHidingException, cctest/test-api/TryCatchAndFinally
Review URL: http://codereview.chromium.org/6526016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6809 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is based on the structore used in chromium with a script wrapping the call to gyp itself and the default processing of common.gypi.
It is possible to build all our targets on Intel Linux for all architectures (ia32, x64 and ARM simulator). When this is committed I wil take a look at Windows.
See the README.txt file in the changelist for the current way of using it.
Review URL: http://codereview.chromium.org/5701001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6000 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
