deferred code snippets are highly stylized. They always make a call
to a stub or the runtime and then return. This change takes advantage
of that.
Creating a deferred code object now captures a snapshot of the
registers in the virtual frame. The registers are automatically saved
on entry to the deferred code and restored on exit.
The clients of deferred code must ensure that there is no change to
the registers in the virtual frame (eg, by allocating which can cause
spilling) or to the stack pointer. That is currently the case.
As a separate change, I will add either code to verify this constraint
or else code to forbid any frame effect.
The deferred code itself does not use the virtual frame or register
allocator (or even the code generator). It is raw macro assembler
code.
Review URL: http://codereview.chromium.org/118226
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
submitted in revisions 2093, 2094, 2099, and 2106.
There's no evidence that supports that these changes
should be the cause of the unexplained performance
regressions on the intl2 and DHTML page cyclers.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2109 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Change stack alignment on linux to 16 bytes to keep gcc 4.4 happy.
This fixes the mksnapshot segfault without requiring -fno-tree-vectorize
which just avoided the problem by not generating code with movdqa.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2107 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The problem was I incorrectly treated NULL result as failure to fetch
a property with a getter. However, if getter returns zero, it is
manifested as NULL pointer (see added test case).
Good news: that gives another boost as before this CL if getter returned
0, I did another slow lookup.
Review URL: http://codereview.chromium.org/119172
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
immediately if holder has this property or saves binary search on holder if
property doesn't belong to holder. Of course, in the cases when named getter
returns nothing.
That gives ~20% for dom benchmark/Document Object String Get, speeds up overall
dom_perf (not dramatically) and overall score for peacekeeper. Strange, but DOM
part of peacekeepr runs somewhat slower.
Review URL: http://codereview.chromium.org/118118
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2093 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
* Running "system" JavaScript with the debug break flag active leads to slow running code while waiting for the break in non "system" JavaScript (one exception to this it is to try to avoid breaks in the clear mirror cache JavaScript code called when leaving the debugger).
* If this happens while processing RegExp running in native code an infinite loop is created as the stack guard handler for RegExp does not move execution forward
Fixed a GC bug in the interrupt handling for RegExp running in native code.
Added test of debug break while in debug message handler callback and debug break while executing a RegExp.
Review URL: http://codereview.chromium.org/115262
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2074 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
I suggest that the lack of initialization causes issue 358 to happen. In Profiler::Disengage an empty TickSample is inserted in order to wake up the Profiler thread. Issue reporter claims that crash happens in LogTickEvent function. My guess is that frames_couint receives a wild value.
Review URL: http://codereview.chromium.org/113939
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2068 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The goal of this change is to allow longer profiling sessions and preserve memory when profiler isn't started. The buffer starts with 64K and grows until it reaches the upper limit, which is currently set to 50MB --- according to my evaluations, this is enough for at least 20 minutes of GMail profiling. As we're planning to introduce compression for the profiler log, this time boundary will be significantly increased soon.
To make possible unit testing of the new component, I've factored out Logger's utility classes into a separate source file: log-utils.h/cc. Log and LogMessageBuilder are moved there from log.cc without any semantical changes.
Review URL: http://codereview.chromium.org/115814
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
