Also, add user time into heap sample begin events to make '--log-gc' flag alone sufficient for producing heap logs (previously, samples times were extracted from scavenge events which are only logged with '--log' flag).
Review URL: http://codereview.chromium.org/149611
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2461 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
It seems that when calling a method that has two overloaded versions like this:
f(char* format, ...)
f(char* format, va_list args)
with a second pointer argument: f("format", pointer), the second version is picked up.
I've found a description of a similar issue here: http://bugs.gentoo.org/63112
So, to resolve this ambiguity, I've named such LogMessageBuilder's Append functions differently.
Review URL: http://codereview.chromium.org/125125
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2172 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Code addresses are now written as an offset from the previous address for ticks, code move and delete events. Employed backreference and RLE compression for code move and delete events. This gives additional 30% log size reduction for benchmarks run w/o snapshot.
Overall compression results (compared with the revision of V8 having no compression):
- V8: 70% size reduction for benchmarks run w/o snapshot (for reference, gzip gives 87%)
- Chromium: 65% size reduction for public html version of benchmarks (v4) (for reference, gzip gives 90%)
The one obvious opportunity for improving compression results in Chromium is to compress URLs of scripts.
Review URL: http://codereview.chromium.org/125114
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2162 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Two techniques are involved:
- compress repeated line ends (common stack beginnings) by using back references;
- do RLE compression of repeated tick events.
This gives only 5% size reduction on benchmarks run, but this is because tick events are only comprise 10% of file size. Under Chromium winnings are bigger because long repeated samples of idleness are now compressed into a single line.
Tickprocessor will be updated in the next patch.
Review URL: http://codereview.chromium.org/123012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2147 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a trivial per-row compression:
- short aliases are introduced for events and code creation tags;
- in tick events, offsets are used instead of absolute addresses;
- removed 'code-allocation' event, as it seems not used.
The first two options are depend on the new flag: 'compress-log', which is off by default.
On benchmarks run w/o snapshot, this gives 45% log size reduction.
Review URL: http://codereview.chromium.org/119304
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
My assumption that log initialization happens somewhere near the stack's bottom is true for V8's sample shell but isn't true for Chromium, causing many otherwise valid stack addresses to be thrown out. The solution proposed is to save stack pointer value for the outermost JS function in ThreadLocalTop similar to c_entry_fp.
Implemented only for IA-32. Currently I'm not dealing with profiling on ARM and x86-64 anyway.
Review URL: http://codereview.chromium.org/112082
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2086 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When profiler's memory buffer is filled up, profiling is stopped and it is ensured that the last record in the buffer is "profiler,\"pause\"" thus making the end of profiling session explicit. Otherwise DevTools Profiler would need to guess whether the current profiling session has been stopped.
Tested with Chromium.
Review URL: http://codereview.chromium.org/115859
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2072 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The goal of this change is to allow longer profiling sessions and preserve memory when profiler isn't started. The buffer starts with 64K and grows until it reaches the upper limit, which is currently set to 50MB --- according to my evaluations, this is enough for at least 20 minutes of GMail profiling. As we're planning to introduce compression for the profiler log, this time boundary will be significantly increased soon.
To make possible unit testing of the new component, I've factored out Logger's utility classes into a separate source file: log-utils.h/cc. Log and LogMessageBuilder are moved there from log.cc without any semantical changes.
Review URL: http://codereview.chromium.org/115814
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2067 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
This is intended to be used with Chromium. When in resource-saving mode, profiler doesn't consume any resources (sampler and logging is off) until resumed. Then again, when profiler is paused, sampling and logging are turned off.
Tested under Linux and Windows. Also have done preliminary testing with Chromium.
Review URL: http://codereview.chromium.org/113762
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2036 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The goal is to make possible having --prof flag always enabled in Chromium. Currently we can't do this because --prof causes compiler and gc to log code creations / moves / deletes which aren't needed until we start profiling. With LogCompiledFunctions it will be possible not to log anything until we start profiling. When started, the current map of compiled functions will be logged and compiler / gc logging will be enabled to update current state. When profling is stopped, logging will be turned off again.
Funny that testing code is actually much longer and complex than function code.
Review URL: http://codereview.chromium.org/112036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2009 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This will enable reading profiler log in Chrome. The current implementation of memory buffer is trivial (fixed size buffer, no memory recycling) but enough to start end-to-end DevTools Profiler implementation. Later it will be enhanced.
Review URL: http://codereview.chromium.org/108011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1870 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
(generic state inside V8) in the API to allow the V8 shell to run all
the mjsunit tests with heap protection on.
These state changes are only taken when built with
ENABLE_HEAP_PROTECTION. The two states OTHER and EXTERNAL are treated
the same because we will not properly reenter OTHER through the API.
Review URL: http://codereview.chromium.org/56060
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1643 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- String traversal test data (now in a zone)
- Debug message thread (now joined on exit)
- Threading test threads (now joined on exit)
- Changed message tests framework to cope with valgrind
Also, fixed a bug where we'd try to delete stack-allocated objects
when tearing down v8. Good times.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1622 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
JavaScriptFrameIterator is templatized on the iterator type and renamed to JavaScriptFrameIteratorTemp.
The original JSFI is now a typedef for JavaScriptFrameIteratorTemp<StackFrameIterator>. Because of templatizing, JSFI code is moved to frames-inl.h
StackTraceFrameIterator moved to frames.*
Implemented SafeStackFrameIterator which wraps StackFrameIterator and have the same interface. It performs additional checks of stack addresses prior to delegating to StackFrameIterator. SafeSFI is used in an another specialization of JavaScriptFrameIteratorTemp template to perform safe JS frames iteration on sampler ticks.
I haven't took an advantage of having multiple stack frames in tickprocessor yet.
Review URL: http://codereview.chromium.org/39009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1404 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
This change introduces a log message builder which builds the log message in a static string buffer instead of formatting the log message through fprintf. Currently this message can only be written to a file afterwards.
Changed the code related events to use the log message builder.
Review URL: http://codereview.chromium.org/20406
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1284 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Thus, instead of the following profiler records:
1.5% 1.5% LazyCompile: <anonymous>
we'll now have these:
1.5% 1.5% LazyCompile: <anonymous> richards.js:309
Basically, I translated two functions from messages.js into C++.
In the next CL I will update messages.js to use added native functions.
Review URL: http://codereview.chromium.org/19537
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1216 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of the generated code. These can be used by the profiler to
categorize the ticks that occur within generated code and thereby show
more detailed information about where time is spent in generated code.
For instance, this is what the profiler displayed for a simple regexp
benchmark with irregexp-native before:
[JavaScript]:
total nonlib name
87.2% 87.2% RegExp: (?:\w*\W+)*
This is what we can display now:
[JavaScript]:
total nonlib name
87.2% 87.2% RegExp: (?:\w*\W+)*
- 53.0% 56.7% BranchOrBacktrack
- 14.9% 59.8% CheckCharacterLT
- 13.7% 20.4% CheckStackLimit
- 6.7% 6.7% SafeCall
- 2.7% 7.0% CheckCharacterGT
- 2.4% 2.4% SafeReturn
- 2.1% 2.1% LoadCurrentCharacter
- 1.8% 1.8% PushRegister
- 0.9% 0.9% PopRegister
- 0.9% 0.9% AdvanceRegister
- 0.3% 0.3% PopCurrentPosition
- 0.3% 0.3% CheckGreedyLoop
- 0.0% 20.4% PushBacktrack
- 0.0% 22.3% CheckCharacter
- 0.0% 2.4% IfRegisterLT
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix for non-empty assertion in debug mode (string representation of empty arguments is a single space, not an empty string).
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@733 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Changed the structure of regexp objects from having two internal
fields to having a single field containing a fixed array, since it's
easier to store the whole fixed array in the cache.
- Move printing of the command to after printing std{err,out} in the
compact progress indicators in the test framework.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@579 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
escape commas.
- Fixed issue with block-comparing unaligned strings on arm.
- Added short documentation to one of the Persistent constructors.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@554 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the shell sample don't print the result of executing a script, only
evaluating expressions.
Fixed issue when building samples on Windows using a shared V8
library. Added visibility option on Linux build which makes the
generated library 18% smaller.
Changed build system to accept multiple build modes in one build and
generate seperate objects, libraries and executables for each mode.
Removed deferred negation optimization (a * -b => -(a * b)) since this
visibly changes operand conversion order.
Improved parsing performance by introducing stack guard in preparsing.
Without a stack guard preparsing always bails out with stack overflow.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fixed the handling of '>' and '<=' to use right-to-left conversion and left-to-right evaluation as specified by ECMA-262.
Fixed a branch elimination bug on the ARM platform where incorrect code was generated because of overly aggressive branch elimination.
Improved performance of code that repeatedly assigns the same function to the same property of different objects with the same map.
Untangled DEBUG and ENABLE_DISASSEMBLER defines. The disassembler no longer expects DEBUG to be defined.
Added platform-nullos.cc to serve as the basis for new platform implementations.
git-svn-id: http://v8.googlecode.com/svn/trunk@9 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added a few samples and support for building them. The samples include a simple shell that can be used to benchmark and test V8.
Changed V8::GetVersion to return the version as a string.
Added source for lazily loaded scripts to snapshots and made serialization non-destructive.
Improved ARM support by fixing the write barrier code to use aligned loads and stores and by removing premature locals optimization that relied on broken support for callee-saved registers (removed).
Refactored the code for marking live objects during garbage collection and the code for allocating objects in paged spaces. Introduced an abstraction for the map word of a heap-allocated object and changed the memory allocator to allocate executable memory only for spaces that may contain code objects.
Moved StringBuilder to utils.h and ScopedLock to platform.h, where they can be used by debugging and logging modules. Added thread-safe message queues for dealing with debugger events.
Fixed the source code reported by toString for certain builtin empty functions and made sure that the prototype property of a function is enumerable.
Improved performance of converting values to condition flags in generated code.
Merged disassembler-{arch} files.
git-svn-id: http://v8.googlecode.com/svn/trunk@8 ce2b1a6d-e550-0410-aec6-3dcde31c8c00