Introduce Logger::LogCompiledFunctions that logs current map of compiled code.

Introduce Logger::LogCompiledFunctions that logs current map of compiled code.

The goal is to make possible having --prof flag always enabled in Chromium.  Currently we can't do this because --prof causes compiler and gc to log code creations / moves / deletes which aren't needed until we start profiling.  With LogCompiledFunctions it will be possible not to log anything until we start profiling.  When started, the current map of compiled functions will be logged and compiler / gc logging will be enabled to update current state.  When profling is stopped, logging will be turned off again.

Funny that testing code is actually much longer and complex than function code.

Committed: http://code.google.com/p/v8/source/detail?r=2009

[Søren Thygesen Gjesse, 2009-05-19 12:40:14]

Please address the allocation issues in the heap traversal.

http://codereview.chromium.org/112036/diff/1/3
File src/log.cc (right):

http://codereview.chromium.org/112036/diff/1/3#newcode1117
Line 1117: // new compiled code, we're fine with it.
It will not work to have allocations while using the heap iterator even if you
don't care about the allocated objects. Allcation can cause GC which will leave
the heap iterator in an udefined state.

You should assert no allocation here

AssertNoAllocation no_alloc;

And then you don't have to use handles. This means that you will have to collect
the SharedFunctionInfo objects in an array and create the log events afterwards.

http://codereview.chromium.org/112036/diff/1/4
File src/log.h (right):

http://codereview.chromium.org/112036/diff/1/4#newcode217
Line 217: // Logs all compiled functions found on heap.
found on -> in the

http://codereview.chromium.org/112036/diff/1/5
File test/cctest/test-log.cc (right):

http://codereview.chromium.org/112036/diff/1/5#newcode413
Line 413: i::Heap::CollectAllGarbage();
Add

AssertNoAllocation no_alloc

here to ensure that there can be no GC's until the call to LogCompiledFunctions.

http://codereview.chromium.org/112036/diff/1/5#newcode462
Line 462: 
Maybe repeat or reference the comment on why the -1 is here.

[Mikhail Naganov, 2009-05-19 15:39:23]

Thanks for useful comments!

http://codereview.chromium.org/112036/diff/1/3
File src/log.cc (right):

http://codereview.chromium.org/112036/diff/1/3#newcode1117
Line 1117: // new compiled code, we're fine with it.
On 2009/05/19 12:40:14, Søren Gjesse wrote:
> It will not work to have allocations while using the heap iterator even if you
> don't care about the allocated objects. Allcation can cause GC which will
leave
> the heap iterator in an udefined state.
> 
> You should assert no allocation here
> 
> AssertNoAllocation no_alloc;
> 
> And then you don't have to use handles. This means that you will have to
collect
> the SharedFunctionInfo objects in an array and create the log events
afterwards.

Things are more tricky here. As you've said, we don't want GC activity during
SFIs collection, but then, as we process them, GCs are unavoidable due to
GetScriptLineNumber calls (and these are unavoidable because otherwise we'll
have no line numbers).

So now I'm using an array of SFI _handles_.

Please examine the new version.

http://codereview.chromium.org/112036/diff/1/4
File src/log.h (right):

http://codereview.chromium.org/112036/diff/1/4#newcode217
Line 217: // Logs all compiled functions found on heap.
On 2009/05/19 12:40:14, Søren Gjesse wrote:
> found on -> in the

Done.

http://codereview.chromium.org/112036/diff/1/5
File test/cctest/test-log.cc (right):

http://codereview.chromium.org/112036/diff/1/5#newcode413
Line 413: i::Heap::CollectAllGarbage();
On 2009/05/19 12:40:14, Søren Gjesse wrote:
> Add
> 
> AssertNoAllocation no_alloc
> 
> here to ensure that there can be no GC's until the call to
LogCompiledFunctions.

Done.

http://codereview.chromium.org/112036/diff/1/5#newcode462
Line 462: 
On 2009/05/19 12:40:14, Søren Gjesse wrote:
> Maybe repeat or reference the comment on why the -1 is here.

A better solution: gathered allocation / disposal code inside ParseLogResult to
keep them close to each other.

[Søren Thygesen Gjesse, 2009-05-19 18:48:24]

LGTM!

This is a nice change.

http://codereview.chromium.org/112036/diff/1003/2006
File test/cctest/test-log.cc (right):

http://codereview.chromium.org/112036/diff/1003/2006#newcode159
Line 159: struct ParseLogResult {
Why not a class?

[Mikhail Naganov, 2009-05-20 09:03:31]

http://codereview.chromium.org/112036/diff/1003/2006
File test/cctest/test-log.cc (right):

http://codereview.chromium.org/112036/diff/1003/2006#newcode159
Line 159: struct ParseLogResult {
On 2009/05/19 18:48:24, Søren Gjesse wrote:
> Why not a class?

Yes, this in no more a POD. Fixed.