I've found that profiling is not working in Debug version.
The actual problem is that sandbox/playgroung configuration is wrong and tgkill syscalls are disallowed.
This patch will make such cases more clear.
Review URL: https://codereview.chromium.org/11961037
Patch from Eugene Klyuchnikov <eustas@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13411 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- perform CPU profiler sampling in the sampler thread as we used to;
- skip sampling in the sampling thread if processing thread is running;
- only install SIGPROF handler when CPU profiling is enabled.
BUG=v8:2364
Review URL: https://codereview.chromium.org/11231002
Patch from Sergey Rogulenko <rogulenko@google.com> and Andrey Kosyakov <caseq@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12985 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The patch introduces CommittedPhysicalMemory function to
the Heap class that reports committed *physical* memory acquired
for the heap from the OS.
It is important because some OSes may defer actual committment on e.g.
first access to the region.
So reporting just plain committed size led to various weird artifacts
like showing V8 allocated memory higher than the whole process
private size.
BUG=v8:2191
Review URL: https://codereview.chromium.org/11066118
Patch from Alexei Filippov <alph@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12793 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The patch introduces CommittedPhysicalMemory function to the Heap class
that reports committed *physical* memory acquired from the OS.
It is important because some OSes may postpone actual commitment on e.g.
first access to the previously committed region.
So reporting just plain committed size led to various weird artifacts
like DevTools showing V8 allocated memory higher than the whole process
private size.
BUG=v8:2191
Review URL: https://codereview.chromium.org/10961042
Patch from Alexei Filippov <alph@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a forward-compatible change to avoid type/naming
conflicts when the Android platform/NDK will update its
<signal.h> header to properly define 'struct sigcontext',
'mcontext_t' and 'ucontext_t'.
In particular:
- Do not define 'struct sigcontext.h' to avoid
conflicts with the C library definition (which
is different, see below).
- Only provide custom ucontext_t declarations if
the Android <signal.h> doesn't provide it. This can
be tested with a macro check (__BIONIC_HAVE_UCONTEXT_T)
+ Use 'gettid()' on Android since it is available (at all
API levels).
See http://code.google.com/p/android/issues/detail?id=34784
Review URL: https://chromiumcodereview.appspot.com/10829122
Patch from David Turner <digit@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12250 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL:
- Adds a new trait parameter to LazyInstance to let it initialize the instance
without paying the cost of atomic operations (which are expensive on Mac).
This only works for users who don't care about thread-safety and this is now
the default initialization trait used by LazyInstance in v8.
- Reverts the changes that were made in r11010 in isolate.{cc,h}. That lets
Isolate's accessors be as cheap as they were before (but adds one static initializer).
- Adds OS::PostSetup() used to initialize the math functions which depend on CPU features.
That lets the math functions get rid of CallOnce().
BUG=118686
Review URL: https://chromiumcodereview.appspot.com/9873023
Patch from Philippe Liard <pliard@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11198 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change includes two CLs by pliard@chromium.org:
1. http://codereview.chromium.org/9447052/ (Add CallOnce() and simple LazyInstance implementation):
Note that this implementation of LazyInstance does not handle global destructors (i.e. the lazy instances are never deleted).
This CL was initially reviewed on codereview.appspot.com:
http://codereview.appspot.com/5687064/
2. http://codereview.chromium.org/9455088/ (Remove static initializers in v8):
This CL depends on CL 9447052 (adding CallOnce and LazyInstance).
It is based on a patch sent by Digit.
With this patch applied, we have only one static initializer left (in atomicops_internals_x86_gcc.cc). This static initializer populates a structure used by x86 atomic operations. It seems that we can hardly remove it. If possible, it will be removed in a next CL.
This CL also modifies the presubmit script to check the number of static initializers.
BUG=v8:1859
Review URL: https://chromiumcodereview.appspot.com/9666052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
While enabling "-fstack-protector", compiler generates code in
function prologue and epilogue to do stack check. However, without
knowing that 'r1', 'r2' and 'r3' is used/destroyed in inline asm,
compiler assumes that 'r1', 'r2', or 'r3' can be used exclusively,
which leads to a core dump.
Fix to this is quite straightforward, just add clobber list to the
inlineasm.
BUG=None
TEST=manually checked the generated asm code,boot up chrome browser successfully with this modification
Review URL: https://chromiumcodereview.appspot.com/9618017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10977 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The return value of pthread_create is now checked to be 0.
Tests on MIPS boards had some silent and hard to find timeouts and errors related to this.
This ensures a proper error message and shutdown if a thread could not be started.
BUG=
TEST=
Review URL: http://codereview.chromium.org/8497041
Patch from Gergely Kis <gergely@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9945 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
