Since symbols and strings share a common representation, most of this change is about consistently replacing 'String' with 'Name' in all places where property names are expected. In particular, no new logic at all is necessary for maps, property dictionaries, or transitions. :) The only places where an actual case distinction is needed have to do with generated type checks, and with conversions of names to strings (especially in logger and profiler).
Left in some TODOs wrt to the API: interceptors and native getters don't accept symbols as property names yet, because that would require extending the external v8.h.
(Baseline CL: https://codereview.chromium.org/12296026/)
R=verwaest@chromium.org,mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12330012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13811 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes:
* adding the CODE_ADD_LINE_POS_INFO, CODE_START_LINE_INFO_RECORDING, CODE_END_LINE_INFO_RECORDING event and the corresponding functionality.
* adding the JITCodeLineInfo struct to record the code line info. I added this definition because Danno mentioned that "we'd like to cleanup and decouple the external debugging functionality"
* some other small changes.
Review URL: https://chromiumcodereview.appspot.com/12223027
Patch from Chunyang Dai <chunyang.dai@intel.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13686 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 old HashMap class had an explicit member to determine the allocation
policy. The template version matches the approach used already for
lists.
Cleanup some include dependencies and unnecessary forward declarations.
Cleanup some dead code from isolate.h and replace some HEAP macros
with GetHeap().
Review URL: https://chromiumcodereview.appspot.com/9372106
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10806 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
Better support for 'polymorphic' JS and external arrays
Allow keyed store/load stubs to switch between external array and fast JS arrays without forcing a state transition to the generic stub.
There CL consists of two pieces of functionality. First, code stubs for fast element arrays don't immediately transition to the MEGAMORPHIC state when there's a map mismatch. Second, two ICs are cached per map for fast elements, the MONOMORPHIC version, and a new MEGAMORPHIC version that handles two or more different maps and dispatches to shared stubs to perform the array operation.
Review URL: http://codereview.chromium.org/7036016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7935 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allow keyed store/load stubs to switch between external array and fast JS arrays without forcing a state transition to the generic stub.
There CL consists of two pieces of functionality. First, code stubs for fast element arrays don't immediately transition to the MEGAMORPHIC state when there's a map mismatch. Second, two ICs are cached per map for fast elements, the MONOMORPHIC version, and a new MEGAMORPHIC version that handles two or more different maps. Currently, the only array types supported by the MEGAMORPHIC stub are fast elements for objects and JSArrays.
BUG=
TEST=
Review URL: http://codereview.chromium.org/6894003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7917 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Switched to using binary low-level log instead of the textual log used
by the ticks processor. The binary log contains code-related events,
code object names, and their bodies. When writing to the log we ask
glibc to use a larger buffer. To avoid complex processing of the
snapshot log (which is still textual) the serializer emits final
snapshot position to code name mappings that can be quickly be read
without replaying the snapshot log. (This might be useful for the
ticks processor.)
Review URL: http://codereview.chromium.org/6904127
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7729 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Worth mentioning:
- Specialized versions of pixel array and store/loads inside the generic stubs have been removed, since to have parity for all external arrays, 8 different versions would have to be inlined/checked.
- There's a new constant in v8.h for external arrays with pixel array elements.
Review URL: http://codereview.chromium.org/6546036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The main issue was due to multiple recompilations of functions. Now
code objects are grouped by function using SFI object address.
JSFunction objects are no longer tracked, instead we track SFI object
moves. To pick a correct code version, we now sample return addresses
instead of JSFunction addresses.
tools/{linux|mac|windows}-tickprocessor scripts differentiate
between code optimization states for the same function
(using * and ~ prefixes introduced earlier).
DevTools CPU profiler treats all variants of function code as
a single function.
ll_prof treats each optimized variant as a separate entry, because
it can disassemble each one of them.
tickprocessor.py not updated -- it is deprecated and will be removed.
BUG=v8/1087,b/3178160
TEST=all existing tests pass, including Chromium layout tests
Review URL: http://codereview.chromium.org/6551011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
An attempt to retrieve security context for a function may fail if the
destination heap space is in an incomplete state. To fix this, we only
record unknown functions discovered at GC object moves, and then
register them after GC completes.
BUG=crbug/59627
Review URL: http://codereview.chromium.org/3763012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5667 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
The cause for missing functions is that some of them are created
from compiled code (see FastNewClosureStub), and thus not get
registered in profiler's code map.
My solution is to hook on GC visitor to provide JS functions
addresses to profiler, only if it is enabled.
BUG=858
TEST=
Review URL: http://codereview.chromium.org/3417019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5523 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The simple formula "ms = ticks * sampler_interval" doesn't work,
because e.g. on Linux, the actual sampling rate can be 5 times
lower than the one set up in the code. To calculate actual sampling
rate, current time is periodically queried and processed along with
actual sampling ticks count.
Review URL: http://codereview.chromium.org/1539038
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4427 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
- when logging 'open-tag' / 'close-tag' events, don't depend on
FLAG_log (as it may be not enabled, e.g. in Chromium);
- PauseProfiler / ResumeProfiler were supposing that they
use 'is_logging_' var exclusively, thus preventing any
other logging that may be turned on for diagnostic purposes.
Review URL: http://codereview.chromium.org/661246
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3986 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change allows to associate integer tags with blocks of profiler
log events, and repeat calls to 'ResumeProfiler' / 'PauseProfiler' in
order to establsh nested (not necessary properly nested) blocks. By
supporting this, we will be able to match WebInspector's CPU profiler
abilities in DevTools.
I also refactored some testing code.
Review URL: http://codereview.chromium.org/619004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3889 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
As this is only needed for internal profiling (not for DevTools),
the following approach had been chosen:
- during snapshot creation, positions of serialized objects inside
a snapshot are logged;
- then during V8 initialization, positions of deserealized objects
are logged;
- those positions are used for retrieving code objects names from
snapshot creation log, which needs to be supplied to tick processor
script.
Positions logging is controlled with the new flag: --log_snapshot_positions.
This flag is turned off by default, and this adds no startup penalty.
To plug this fix to Golem, the following actions are needed:
- logs created using 'mksnapshot' need to be stored along with VM images;
- tick processor script needs to be run with '--snapshot-log=...' cmdline
argument.
BUG=571
Review URL: http://codereview.chromium.org/551062
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3635 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is needed to show calls to DOM in CPU profiles. I can think
of a better approach like adding specific functions into V8 API
for explicitly providing callback names and modifying bindings codegen
appropriately. My plan is as follows:
- submit this CL;
- implement anything I need to process log data and display DOM
calls in profiles;
- think again about adding specific functions and modifying bindings
codegen.
BUG=http://code.google.com/p/chromium/issues/detail?id=27613
Review URL: http://codereview.chromium.org/402100
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3340 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Turned on with '--log-producers' flag, also needs '--noinline-new' (this is temporarily), '--log-code', '--log-gc'. Not all allocations are traced (I'm investigating.)
Stacks are stored using weak handles. Thus, when an object is collected, its allocation stack is deleted.
Review URL: http://codereview.chromium.org/267077
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3069 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The profile is taken together with constructors profile. In theory, it
should represent a complete heap graph. However, this takes a lot of memory,
so it is reduced to a more compact, but still useful form. Namely:
- objects are aggregated by their constructors, except for Array and Object
instances, that are too hetereogeneous;
- for Arrays and Objects, initially every instance is concerned, but then
they are grouped together based on their retainer graph paths similarity (e.g.
if two objects has the same retainer, they are considered equal);
Review URL: http://codereview.chromium.org/200132
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2903 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I'm planning to use it in DevTools heap profiler. It is a common scenario in debugging memory leaks to enforce GC, then perform an operation, then enforce GC again to check for non-collected (that is, leaked) objects. Using the existing GC extension isn't possible because it doesn't exposed in the normal operation mode of Chromium.
Review URL: http://codereview.chromium.org/159787
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2619 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It is activated with '--log-gc' flag.
JS object size is calculated as its size + size of 'properties' and 'elements' arrays, if they are non-empty. This doesn't take maps, strings, heap numbers, and other shared objects into account.
As Soeren suggested, I've moved ZoneSplayTree from jsregexp to zone, and removed now empty jsregexp-inl header file.
Review URL: http://codereview.chromium.org/159504
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2570 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
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
- 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
