Record allocation stack traces

Record allocation stack traces

This is initial implementation of allocation profiler.

Whenever new object allocation is reported to the HeapProfiler and allocation tracking is on we will capture current stack trace, add it to the collection of the allocation traces (a tree) and attribute the allocated size to the top JS function on the stack.

Format of serialized heap snapshot is extended to include information about recorded allocation stack traces.

This patch is r17301 plus a fix for the test crash in debug mode. The test crashed because we were traversing stack trace when just allocated object wasn't completely configured, in particular the map pointer was incorrect. Invalid Map pointer broke heap iteration required to find Code object for a given pc during stack traversal. The solution is to insert free space filler in the newly allocated block just before collecting stack trace.

BUG=chromium:277984, v8:2949
R=hpayer@chromium.org, loislo@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=17365

[yurys, 2013-10-23 08:33:21]

Hannes, please review the part that changed compared to r17301 which you have
already reviewed. It is in "Patch Set #2" (patch set #1 is exact copy of
r17301).

[loislo, 2013-10-23 10:07:41]

lgtm

[Hannes Payer (out of office), 2013-10-23 10:51:02]

So the problem is that the map pointer is not set in the newly allocated object.
Why don't we install a free space filler with the appropriate size there after
allocating but right before reporting? This should solve the problem and does
not spread the reporting code all over the heap allocation functions. WDYT?

[loislo, 2013-10-23 11:04:48]

On 2013/10/23 10:51:02, Hannes Payer wrote:
> So the problem is that the map pointer is not set in the newly allocated
object.
> Why don't we install a free space filler with the appropriate size there after
> allocating but right before reporting? This should solve the problem and does
> not spread the reporting code all over the heap allocation functions. WDYT?

It will increase the complexity of the code, will cost us a small fraction of
the performance and changes the heap state.
It is not a big problem but I prefer simpler solutions :).

[yurys, 2013-10-23 11:08:05]

On 2013/10/23 10:51:02, Hannes Payer wrote:
> So the problem is that the map pointer is not set in the newly allocated
object.
> Why don't we install a free space filler with the appropriate size there after
> allocating but right before reporting? This should solve the problem and does
> not spread the reporting code all over the heap allocation functions. WDYT?

That was another option we considered but Ilya argued against that approach as
it would increase complexity of the code. Also we would probably have to do
similar work in the generated code. I like the current approach slightly better
as it doesn't require modifying the current allocation logic except reporting
allocations in appropriate places. Ilya what do you think?

[loislo, 2013-10-23 11:12:45]

On 2013/10/23 11:08:05, Yury Semikhatsky wrote:
> On 2013/10/23 10:51:02, Hannes Payer wrote:
> > So the problem is that the map pointer is not set in the newly allocated
> object.
> > Why don't we install a free space filler with the appropriate size there
after
> > allocating but right before reporting? This should solve the problem and
does
> > not spread the reporting code all over the heap allocation functions. WDYT?
> 
> That was another option we considered but Ilya argued against that approach as
> it would increase complexity of the code. Also we would probably have to do
> similar work in the generated code. I like the current approach slightly
better
> as it doesn't require modifying the current allocation logic except reporting
> allocations in appropriate places. Ilya what do you think?

I think that the measuring instrument shouldn't change the measured values.

[Hannes Payer (out of office), 2013-10-23 11:37:06]

Additionally, since we fixed the allocation behavior that everything goes
through Heap::AllocateRaw, can you add the logging to AllocateRaw and completely
remove it from space.*.
That would be awesome. space should not now about logging at all.

[Hannes Payer (out of office), 2013-10-23 11:44:29]

Ignore my last comment, we are not there yet. But we may be soon.

[yurys, 2013-10-23 11:47:54]

On 2013/10/23 11:44:29, Hannes Payer wrote:
> Ignore my last comment, we are not there yet. But we may be soon.

Why not? I guess we can move the instrumentation into heap.cc and get rid of
PagedSpace::AllocationType.

[Hannes Payer (out of office), 2013-10-23 11:51:08]

On 2013/10/23 11:47:54, Yury Semikhatsky wrote:
> On 2013/10/23 11:44:29, Hannes Payer wrote:
> > Ignore my last comment, we are not there yet. But we may be soon.
> 
> Why not? I guess we can move the instrumentation into heap.cc and get rid of
> PagedSpace::AllocationType.

There are still allocation sites that call directly into space. We are currently
trying to make every allocation go through the heap AllocateRaw bottleneck. As
soon as that is true for the whole codebase, we can move the logging to heap.

[yurys, 2013-10-23 12:06:28]

On 2013/10/23 10:51:02, Hannes Payer wrote:
> So the problem is that the map pointer is not set in the newly allocated
object.
> Why don't we install a free space filler with the appropriate size there after
> allocating but right before reporting? This should solve the problem and does
> not spread the reporting code all over the heap allocation functions. WDYT?

Done. I reverted changes to spaces* and added a code to mark allocated block as
free space just before the stack iteration (patch delta #5 in
src/allocation-tracker.cc). PTAL.

[Hannes Payer (out of office), 2013-10-24 08:18:02]

LGTM

[yurys, 2013-10-24 09:27:06]

Committed patchset #6 manually as r17365 (presubmit successful).