- 03 Jul, 2013 14 commits
-
-
olivf@chromium.org authored
BUG= R=danno@chromium.org Review URL: https://codereview.chromium.org/17229005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15473 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/18068007 Patch from Haitao Feng <haitao.feng@intel.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15472 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
The test flakes on "V8 GC Stress" bots and the sample looks like this: [Top down]: 90 0 (root) [-1] #0 1 1 1 (program) [-1] #0 2 89 89 (garbage collector) [-1] #0 3 which means that almost all samples are inside GC and we have no |start| node in the collected profile. Running the test with different combinations of --gc-interval=500 and --stress-compaction flags gives the results quoted below. They don't give a ground to require |start| node presense in the profile when doing GC stress testing. So this change makes the |start| node optional in the collected profile if GC stress testing is on. $ ./out/ia32.debug/cctest --gc-interval=500 --stress-compaction --trace-gc test-cpu-profiler/FunctionCallSample [10291] 76 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 49.5 ms (+ 0.2 ms in 1 steps since start of marking, biggest step 0.2 ms) [StackGuard GC request] [GC in old space requested]. [10291] 110 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 25.3 ms [Logger::LogCompiledFunctions] [GC in old space requested]. [10291] 135 ms: Mark-sweep 0.4 (17.8) -> 0.4 (17.8) MB, 22.8 ms [Logger::LogAccessorCallbacks] [GC in old space requested]. [10291] 179 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 39.9 ms (+ 0.1 ms in 1 steps since start of marking, biggest step 0.1 ms) [Runtime::PerformGC] [GC in old space forced by flags]. [10291] 209 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 29.1 ms (+ 0.1 ms in 1 steps since start of marking, biggest step 0.1 ms) [Runtime::PerformGC] [GC in old space forced by flags]. [10291] 240 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 29.1 ms (+ 0.1 ms in 1 steps since start of marking, biggest step 0.1 ms) [Runtime::PerformGC] [GC in old space forced by flags]. [Top down]: 99 0 (root) [-1] #0 1 4 4 start [-1] #16 3 93 93 (garbage collector) [-1] #0 4 2 2 (program) [-1] #0 2 $ ./out/ia32.debug/cctest --gc-interval=500 --trace-gc test-cpu-profiler/FunctionCallSample [10328] 46 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 14.9 ms [Logger::LogCompiledFunctions] [GC in old space requested]. [10328] 61 ms: Mark-sweep 0.4 (17.8) -> 0.4 (17.8) MB, 12.9 ms [Logger::LogAccessorCallbacks] [GC in old space requested]. [10328] 65 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.3 ms [Runtime::PerformGC]. [10328] 67 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.3 ms [Runtime::PerformGC]. [10328] 69 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 70 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 72 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 73 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 75 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 77 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 78 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 80 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 81 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 83 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 85 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 86 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 88 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 89 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 91 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 93 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 94 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.3 ms [Runtime::PerformGC]. [10328] 96 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 97 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 99 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 101 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 102 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 104 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 105 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 107 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 109 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 110 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 112 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 113 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.3 ms [Runtime::PerformGC]. [10328] 115 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 117 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 118 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 120 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 121 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 123 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 125 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 126 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 128 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 129 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 131 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 133 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 134 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 136 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 137 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 139 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 141 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 142 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 144 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.3 ms [Runtime::PerformGC]. [10328] 145 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 147 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 149 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 150 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 152 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 153 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.3 ms [Runtime::PerformGC]. [10328] 155 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 157 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 158 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 160 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 162 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [10328] 163 ms: Scavenge 0.5 (17.8) -> 0.4 (17.8) MB, 1.2 ms [Runtime::PerformGC]. [Top down]: 95 0 (root) [-1] #0 1 12 11 start [-1] #16 3 1 1 bar [-1] #16 4 81 81 (garbage collector) [-1] #0 5 2 2 (program) [-1] #0 2 $ ./out/ia32.debug/cctest --stress-compaction --trace-gc test-cpu-profiler/FunctionCallSample [10355] 76 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 49.9 ms (+ 0.1 ms in 1 steps since start of marking, biggest step 0.1 ms) [StackGuard GC request] [GC in old space requested]. [10355] 110 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 25.5 ms [Logger::LogCompiledFunctions] [GC in old space requested]. [10355] 135 ms: Mark-sweep 0.4 (17.8) -> 0.4 (17.8) MB, 22.9 ms [Logger::LogAccessorCallbacks] [GC in old space requested]. [10355] 189 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 49.8 ms (+ 0.2 ms in 1 steps since start of marking, biggest step 0.2 ms) [StackGuard GC request] [GC in old space requested]. [10355] 234 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 42.5 ms (+ 0.1 ms in 1 steps since start of marking, biggest step 0.1 ms) [StackGuard GC request] [GC in old space requested]. [10355] 278 ms: Mark-sweep 0.5 (17.8) -> 0.4 (17.8) MB, 42.5 ms (+ 0.1 ms in 1 steps since start of marking, biggest step 0.1 ms) [StackGuard GC request] [GC in old space requested]. [Top down]: 135 0 (root) [-1] #0 1 6 6 start [-1] #16 3 127 127 (garbage collector) [-1] #0 4 2 2 (program) [-1] #0 2 BUG=None R=jkummerow@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/18068012 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15471 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
The profile may look a bit different on the bots (see below). We expected this only under GC stress testing, the change makes regular expectations the same. [Top down]: 68 0 (root) [-1] #0 1 1 1 (program) [-1] #0 2 67 65 start [-1] #16 3 2 0 (unresolved function) [-1] #0 4 2 2 apply [-1] #0 5 BUG=None TBR=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18331012 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15470 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/18643002 Patch from Jochen Eisinger <jochen@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15469 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
When pc is inside FunctionApply builtin function the top frame may be either 2) Internal stack frame created by FunctionApply itself. In this case we know its caller's pc and can correctly resolve calling function. 1) Frame of the calling JavaScript function that invoked .apply(). In this case we have no practical reliable way to find out the caller's pc so we mark the caller's frame as 'unresolved'. All this logic is implemented in ProfileGenerator. SafeStackFrameIterator is extended to provide type of the current top stack frame (iteration actually starts from the caller's frame as we know top function from pc). BUG=252097 R=jkummerow@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/18269003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15468 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18638002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15467 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
R=danno@chromium.org Review URL: https://codereview.chromium.org/18363007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15466 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
In case tcmalloc is not being used, the malloc()/free() overhead can be significant for several runtime functions like StringReplace. Therefore we reintroduce the runtime_zone into Isolate and reenable the segment caching functionality of Zone. There's now also a simpler version of ZoneScope w/o nesting capabilities. BUG=v8:2759 R=danno@chromium.org, yangguo@chromium.org Review URL: https://codereview.chromium.org/18635003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15465 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jkummerow@chromium.org authored
This adds the gyp flag v8_enable_i18n_support (off by default), and the v8 flag FLAG_enable_i18n (on by default, but without effect if v8_enable_i18n_support is off). BUG=v8:2745 R=cira@chromium.org, danno@chromium.org, jkummerow@chromium.org Review URL: https://codereview.chromium.org/18487004 Patch from Jochen Eisinger <jochen@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15464 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=mvstanton@chromium.org BUG=v8:2756 Review URL: https://codereview.chromium.org/18572009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15463 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=jkummerow@chromium.org BUG= Review URL: https://codereview.chromium.org/17599007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15462 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/18592006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15461 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
danno@chromium.org authored
R=mstarzinger@chromium.org Review URL: https://chromiumcodereview.appspot.com/18621002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15460 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Jul, 2013 25 commits
-
-
jkummerow@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/18465003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15459 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/18497003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15458 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
Fixed a couple of places where stored pointer to the isolate can be used instead of reading from thread local storage. BUG=None R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18418003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15457 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/17620008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15456 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/18089024 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15455 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
titzer@chromium.org authored
BUG= Review URL: https://codereview.chromium.org/18508002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15454 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=ulan@chromium.org BUG=v8:2754 Review URL: https://codereview.chromium.org/18500003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15453 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ulan@chromium.org authored
If the top optimized code in call stack is at the point that does not support deoptimization, then treat the maps in the code as strong pointers. Note that other optimized code in call stack must support deoptimization because of the call instruction with side-effects. BUG=217858,v8:2073 R=mstarzinger@chromium.org Review URL: https://chromiumcodereview.appspot.com/16955008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15452 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jkummerow@chromium.org authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18211004 Patch from Haitao Feng <haitao.feng@intel.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15451 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jkummerow@chromium.org authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18263002 Patch from Weiliang Lin <weiliang.lin2@gmail.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15450 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jkummerow@chromium.org authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/18324010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15447 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
The test falkes on Windows bots as number of samples is not enough. This change increases sampling interval for the test on Windows. BUG=2628 TBR=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18532003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15446 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
R=danno@chromium.org Review URL: https://codereview.chromium.org/18375004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15445 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rossberg@chromium.org authored
This reverts https://code.google.com/p/v8/source/detail?r=15265, due to performance regression. TBR=jkummerow@chromium.org BUG= Review URL: https://codereview.chromium.org/18525002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15444 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rossberg@chromium.org authored
TBR=jkummerow@chromium.org BUG= Review URL: https://codereview.chromium.org/18524002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15443 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
machenbach@chromium.org authored
This file will be regularly updated with the chromium revision to be used by performance test buildbots. R=danno@chromium.org Review URL: https://codereview.chromium.org/18244003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15442 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18487003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15441 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/18509002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15440 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/18287003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15439 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
R=danno@chromium.org, mstarzinger@chromium.org Review URL: https://codereview.chromium.org/18476004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15438 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
R=danno@chromium.org Review URL: https://codereview.chromium.org/18487002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15437 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
When current function is FunctionCall builtin we have no reliable way to determine its caller function (in many cases the top of the sampled stack contains address of the caller but sometimes it does not). Instead of dropping the sample or its two top frames we simply mark the caller frame as '(unresolved function)'. It seems like a better approach that dropping whole sample as knowing the top function and the rest of the stack the user should be able to figure out what the caller was. This change adds builtin id to CodeEntry objects. It will be used later to add similar top frame analysis for FunctionApply and probably other builtins. BUG=None TBR=loislo@chromium.org Review URL: https://codereview.chromium.org/18422003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15436 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
This adds an ASSERT that the entry_stack_ of the Isolate is empty upon destruction. The default Isolate is an exception here, as it may still contain an entry stack item upon destruction. R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18247004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15435 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
This reverts commit r15426. The new test fails in Debug mode. BUG=None TBR=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18478002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15434 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
loislo@chromium.org authored
Each CpuProfileNode has resource_name string property. It cost us N * strlen(resource_name) where N is number of functions in the collected profile. We could transfer script_id instead of resource_name so it would reduce transfer size and help us to solve the problem with evals and sourceURL. BUG=none TEST=test-cpu-profiler/CollectCpuProfile R=jkummerow@chromium.org, yurys@chromium.org Committed: https://code.google.com/p/v8/source/detail?r=15429 Review URL: https://codereview.chromium.org/17642009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15433 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Jul, 2013 1 commit
-
-
palfia@homejinni.com authored
Different register must be used to pass the test on target hardware. BUG= TEST=cctest/test-api/SetFunctionEntryHook Review URL: https://codereview.chromium.org/18368002 Patch from Balazs Kilvady <kilvadyb@homejinni.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15432 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-