Observation in the normal case (Object.observe, default accept types, one observer) now allocates fewer objects and unobservation no longer needs to scan and splice an InternalArray -- making the combined speed of observe/unobserve about 200% faster.
This patch implements the following optimizations:
-objectInfo is initially created without any connected objects or arrays. The first observer is referenced directly by objectInfo, and when a second observer is added, changeObservers converts to a mapping of callbackPriority->observer, which allows for constant time registration/de-registration.
-observer.accept and objectInfo.performing are conceptually the same data-structure. This is now directly represented as an abstract "TypeMap" which can later be optimized to be a smi in common cases, (e.g: https://codereview.chromium.org/19269007/).
-objectInfo observers are only represented by an object with an accept typeMap if the set of accept types is non-default
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/19541010
Patch from Rafael Weinstein <rafaelw@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16343 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r16319 (22e0380)
Original commit message:
By setting this flag assertions behind --debug-code will trigger a
breakpoint instead of a call into Abort. This eases debugging, as the
call site is less cluttered and the backtrace starts where it should.
BUG=
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16342 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The test has been marked as intermittently failing since 2011 and since that "code-creation" event signature has changed a bit. I updated the parser in the test but that revealed another issue: "code-creation" events with type 'Script' didn't match functions with type 'LazyCompile' retrieved during the heap traversal because the later had name " :1:1" which didn't match the script's name.
BUG=v8:2857
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/22824043
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16331 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Move all of the CPU detection logic to the CPU class, and make
all other code use the CPU class for feature detection.
This also fixes the ARM CPU feature detection logic, which was
based on fragile string search in /proc/cpuinfo. Now we use
ELF hwcaps if available, falling back to sane(!!) parsing of
/proc/cpuinfo for CPU features.
The ia32 and x64 code was also cleaned up to make it usable
outside the assembler.
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/23401002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16315 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
New flag is added that allows to specify CPU profiler sampling rate in microseconds as command line argument. It was tested to work fine with 100us interval(currently it is 1ms). Default values are kept the same as in the current implementation. The new implementation is enabled only on POSIX platforms which use signals to collect samples. Other platforms that pause thread being sampled are to follow.
SIGPROF signals are now sent on the profiler event processor thread to make sure that the processing thread does fall far behind the sampling.
The patch is based on the previous one that was rolled out in r13851. The main difference is that the circular queue is not modified for now.
On Linux sampling for CPU profiler is initiated on the profiler event processor thread, other platforms to follow.
CPU profiler continues to use SamplingCircularQueue, we will probably replace it with a single sample buffer when Mac and Win ports support profiling on the event processing thread.
When --prof option is specified profiling is initiated either on the profiler event processor thread if CPU profiler is on or on the SignalSender thread as it used to be if no CPU profiles are being collected.
ProfilerEventsProcessor::ProcessEventsAndDoSample now waits in a tight loop, processing collected samples until sampling interval expires. To save CPU resources I'm planning to change that to use nanosleep as only one sample is expected in the queue at any point.
BUG=v8:2814
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/21101002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16310 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added a console parameter for source map to the tick processor.
The tickprocesspor reads in the source maps and uses it to output the original filename, line number and column in the profile.
Modified d8 to output column numbers into the log, since this is needed to do source mapping.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/22897021
Patch from Daniel Kurka <dankurka@google.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16307 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The flag restricts hydrogen.cfg output to functions passing the filter,
similar to what --hydrogen-filter does for optimization in general.
This is useful for investigating large repro cases where tracing all
functions would lead to an impractically large hydrogen.cfg file, but
restricting optimization using --hydrogen-filter is undesirable
(e.g. because it might cause the issue to no longer reproduce).
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/22926025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16302 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
V8 stores this information directly in the map of the wrapper, however,
it is not invalidated when the prototype of the wrapper is changed, so
once the bit is set, it is no longer possible to override valueOf.
This bug is currently hidden in Chrome since the i18n extension always
modifies the String.prototype, and so the optimization never kicks in.
Disabling the optimization temporarily allows for snapshotting i18n now.
BUG=v8:2855
R=yangguo@chromium.org
TEST=mjsunit/regress/regress-2855.js
Review URL: https://codereview.chromium.org/23060030
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16292 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
