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 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
The preprocessor defines ENABLE_LOGGING_AND_PROFILING and ENABLE_VMSTATE_TRACKING has been removed as these where required to be turned on for Crankshaft to work. To re-enable reducing the binary size by leaving out heap and CPU profiler a new set of defines needs to be created.
R=ager@chromium.org
BUG=v8:1271
TEST=all
Review URL: http://codereview.chromium.org//7350014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8622 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
o The thread local state in an isolate has to be initialized before
it's used.
o v8::Locker was incorrectly tracking whether it's the topmost one.
o Waking the profiler thread on shutdown should not leave the
semaphore counter in an inconsitent state.
R=fschneider@chromium.org
BUG=v8:1522
TEST=cctest/test-lockers/Regress1433
Review URL: http://codereview.chromium.org/7309013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8537 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
Patch by Dmitry Lomov.
pthreads implementations are free to reuse pthread_t (thread id) after
the thread has died. This change gets rid of ThreadHandle class and
replaces it with v8-managed thread identifiers.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7575 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Windows compilation is broken. Will fix and reland later.
This reverts commit fe13ffaa6d0c3435bfe1ae930813e456650ec980.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
the only platform that it works on is linux (using the prctl API to set the
names of the threads). Other platforms are setup to build properly if the
flag is set, but their thread names are not currently set.
Patch by Mark Lam from Hewlett-Packard Development Company, LP
Review URL: http://codereview.chromium.org/6070009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6141 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Since 2.6.31 perf_events interface has been available in the
kernel. There's a nice tool called "perf" (linux-2.6/tools/perf) that
uses this interface and provides capabilities similar to oprofile. The
simplest form of its usage is just dumping the raw log (trace) of
events generated by the kernel. In this patch I'm adding a script
(tools/ll_prof.py) to build profiles based on perf trace and our code
log. All the heavy-lifting is done by perf. Compared to oprofile agent
this approach does not require recompilation and supports code moving
garbage collections.
Expected usage is documented in the ll_prof's help. Basically one
should run V8 under perf passing --ll-prof flag and then the produced
logs can be analyzed by tools/ll_prof.py.
The new --ll-prof flag enables logging of generated code object
locations and names (like --log-code), and also of their bodies, which
can be later disassembled and annotated by the script.
Review URL: http://codereview.chromium.org/3831002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is to make possible enabling usage of the new profiling subsystem
in Chromium without much hassle. The idea is pretty simple: unless the
new profiling API is used, all works as usual, as soon as Chromium
starts to use the new API, it will work too.
Review URL: http://codereview.chromium.org/1635005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4382 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In browser (DevTools) mode, only non-native JS code and callbacks are reported.
Also, added "(garbage collector)" entry which accumulates samples count in GC state.
Trying to display "(compiler)" and "(external)" only brings confusion,
because it ends up in displaying scripts code under "(compiler)" node, and DOM
event handlers under "(external)" node, which looks weird.
Review URL: http://codereview.chromium.org/1523015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4357 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The problem appeared due to a fact that stubs doesn't create a stack
frame, reusing the stack frame of the caller function. When building
stack traces, the current function is retrieved from PC, and its
callees are retrieved by traversing the stack backwards. Thus, for
stubs, the stub itself was discovered via PC, and then stub's caller's
caller was retrieved from stack.
To fix this problem, a pointer to JSFunction object is now captured
from the topmost stack frame, and is saved into stack trace log
record. Then a simple heuristics is applied whether a referred
function should be added to decoded stack, or not, to avoid reporting
the same function twice (from PC and from the pointer.)
BUG=553
TEST=added to mjsunit/tools/tickprocessor
Review URL: http://codereview.chromium.org/546089
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
available. We use this to ensure that snapshots on MacOSX can
use SSE2 instructions. Also clean up and assertify the
handling of things we can't do when we are generating a
snapshot. Fix a bug in the new serialization tests where
they activated Snapshot::enable() too late after code had been
generated that assumed no snapshots.
Review URL: http://codereview.chromium.org/391051
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3301 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Tag Mac OS X VM regions allocated by V8. This has no effect other than making
it possible to identify V8 allocations in the vmmap(1) memory profiling tool,
to get a better idea of an embedder's/Chrome's memory usage.
CRBUG=23455
TEST=Tested by running vmmap(1) and looking for "Memory tag=255" in the output.
Review URL: http://codereview.chromium.org/244051
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3001 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previous implementation of sampler for OS X was copied from the Linux one. But BSD (OS X) and Linux has a very important difference in signal handling. LinuxThreads doesn't support the notion of process-directed signals. So, the SIGPROF signal was directed to the thread that installed the handler---the V8 thread. But on BSD, signal handling is implemented according to POSIX spec, where process-directed signal is to be handled by an arbitrary selected thread. By a coincidence, in V8's sample shell and in Chromium's test shell, V8's thread was picked almost every time, so sampling seemed working. But not in case of Chromium.
So, I've changed the implementation of profiler sampler to use the same scheme as on Windows---a dedicated thread with high priority is used to periodically pause and sample V8's thread.
Review URL: http://codereview.chromium.org/147150
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2315 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This issue was raised by Brett Wilson while reviewing my changelist for readability. Craig Silverstein (one of C++ SG maintainers) confirmed that we should declare one namespace per line. Our way of namespaces closing seems not violating style guides (there is no clear agreement on it), so I left it intact.
Review URL: http://codereview.chromium.org/115756
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
a reason to stack allocate large chunks of stack space.
- Runtime_GetCFrames used to allocate a frame size of 52040 bytes.
- PreallocatedMemoryThread::Run used to allocate 32784 bytes.
- Fixed StringStream overflow conditions.
Review URL: http://codereview.chromium.org/67197
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1729 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
and unprotecting it when (re)entering. The functionality is enabled
by the flag --protect-heap and requires V8 to be built with
ENABLE_HEAP_PROTECTION and ENABLE_LOGGING_AND_PROFILING defined.
Implemented on Linux and Windows but not yet for other platforms.
Review URL: http://codereview.chromium.org/53004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1595 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Initially the platform socket implementation has been moved from the Linux, Mac OS and FreeBSD platforms to the POSIX platform.
If implementation which ends up in the POSIX platform at some point cannot be the same across POSIX platforms the implementation can easily be moved back into the individual POSIX "complient" platforms.
Review URL: http://codereview.chromium.org/51001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1583 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The code has been compiled and tested on Windows, Linux and Mac OS.
The FreeBSD version is a copy of the Linux version which should work on FreeBSD as well. According to the FreeBSD documentation clock_gettime is part of the standard C library so the assumption is that no additional link libraries is required for FreeBSD.
Review URL: http://codereview.chromium.org/48123
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1526 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The new Socket class is an encapsulation of the standard BSD socket API. As it depends on platform specific include files and have some slight platform variations it is part of the platform code.
On Mac OS only the option SO_REUSEADDR is set to true for server sockets. Running the test required it as the bound listener socket would sometimes end up in TIME_WAIT. On Windows and Linux this has never been observed (given the client end of the socket is closed before the server end).
The code has been tested on Windows, Linux and Mac OS. The FreeBSD version is a copy of the Linux version but has not been compiled nor tested.
Missing Xcode project updates.
Review URL: http://codereview.chromium.org/27085
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1349 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently only two stack frames are sampled (current function and its caller).
Output of tick processor looks like this:
[Call profile]:
total call path
15.2% LazyCompile: am3 crypto.js:108 <- LazyCompile: montReduce crypto.js:583
6.5% LazyCompile: am3 crypto.js:108 <- LazyCompile: bnpSquareTo crypto.js:431
2.9% Builtin: KeyedStoreIC_Generic <- LazyCompile: montReduce crypto.js:583
2.3% LazyCompile: am3 crypto.js:108 <- LazyCompile: bnpMultiplyTo crypto.js:415
Tested under Windows, Linux and OS X.
Review URL: http://codereview.chromium.org/21403
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1292 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
