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
In the RegExpUnparser::VisitText(RegExpText* that, void* data) function always RegExpUnparser::VisitAtom function called via that->elements()->at(i).data.u_atom->Accept(this, data); even if the type of the object is RegExpCharacterClass.
The problem shows using g++ 4.7(.2, .3) since r16232, since GCC optimizes virtual method calls to direct calls based on __final/final hints. Tested on MIPS and x64:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000588928 in v8::internal::RegExpUnparser::VisitAtom(v8::internal::RegExpAtom*, void*) ()
This cleans up the TextElement class to avoid the unsafe+unchecked union access, that caused the crash.
TEST=cctest/test-regexp/ParserRegression
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/22815033
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16289 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
