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
