Instead of globally tracking allocated space limits, which was
not implemented properly anyway (i.e. lack of synchronization
on the reading side), track it per MemoryAllocator (that is
per heap/isolate).
In particular, avoid to call IsBadWritePtr() on Windows, it is
obsolete and Microsoft strongly discourages its usage.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/23903008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16542 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
Committed: https://code.google.com/p/v8/source/detail?r=16343
Review URL: https://codereview.chromium.org/19541010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16539 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Condition variables are synchronization primitives that can be used
to block one or more threads while waiting for condition to become
true.
Right now we have only semaphores, mutexes and atomic operations for
synchronization, which results in quite complex solutions where an
implementation using condition variables and mutexes would be straight
forward.
There's also a performance benefit to condition variables and mutexes
vs semaphores, especially on Windows, where semaphores are kernel
objects, while mutexes are implemented as fast critical sections,
it CAN be beneficial performance-wise to use condition variables
instead of semaphores.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/23548007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Drop the previous Mutex and ScopedLock classes from platform files.
Add new Mutex, RecursiveMutex and LockGuard classes, which are
designed after their C++11 counterparts, so that at some point
we can simply drop our custom code and switch to the C++11
classes. We distinguish regular and recursive mutexes, as the
latter don't work well with condition variables, which will be
introduced by a followup CL.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/23625003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16416 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
The previous Windows issues have been resolved, and we now use GetTickCount64()
on Windows Vista and later, falling back to timeGetTime() with rollover
protection for earlier Windows versions.
BUG=v8:2853
R=machenbach@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/23490015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16413 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
BUG=v8:2853
R=machenbach@chromium.org
Review URL: https://codereview.chromium.org/23469013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
BUG=v8:2853
R=machenbach@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/23295034
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16388 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
All the tests that started crashing create ProfilerEventsProcessor on the stack. After r16284 SamplingCircularQueue buffer is allocated as a field of the queue instead of separate heap object. This increased self size of ProfilerEventsProcessor by about 1Mb. Windows malloc fails to allocate such an object on the stack and crashes.
BUG=
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/23093022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16287 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
All of these values are derived from the self samples count and there is no need to evaluate them in v8 when clients can do that when needed on their side.
Also added unsigned GetHitCount() which should be used instead of double GetSelfSamplesCount(). I'm going to deprecate the latter one once Blink has switched to GetHitCount.
BUG=267595
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/22710006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16119 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If an developer attempts to "subclass" Error by running
`MyError.prototype = new Error();`, then the internal v8::Message object
that's produced and handed off to `window.onerror` handlers is poorly
stringified as "[object Object]".
This patch adjusts the stringification process for these objects to
include not only native Error objects, but also objects that have Error
in their prototype chain, and haven't overwritten Error.toString with
some custom variant.
BUG=2822
R=mstarzinger@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/21761002
Patch from Mike West <mkwst@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16075 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The start and end time are now measured in microseconds and the type is int64_t.
This way it seems more natural as we are going to support submilisecond sampling
rate soon. Also it fixes cctest/test-cpu-profiler/ProfileStartEndTime test
failure caused by comparison between long double and double.
TEST=cctest/test-cpu-profiler/ProfileStartEndTime
BUG=v8:2824
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/22155003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The start and end time are now measured in microseconds and the type is int64_t. This way it seems more natural as we are going to support submilisecond sampling rate soon. Also it fixes cctest/test-cpu-profiler/ProfileStartEndTime test failure caused by comparison between long double and double.
TEST=cctest/test-cpu-profiler/ProfileStartEndTime
BUG=v8:2824
R=alph@chromium.org, bmeurer@chromium.org
Review URL: https://codereview.chromium.org/22172002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16049 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
