It's important that e.g. the header comes first, and the footer last

BUG=v8:2745
R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/18187005

Patch from Jochen Eisinger <jochen@chromium.org>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15476 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=v8:2745
R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/18471005

Patch from Jochen Eisinger <jochen@chromium.org>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15475 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=machenbach@chromium.org

Review URL: https://codereview.chromium.org/18259007

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15474 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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