Provide more functions to CPU profiler (fix issue 858).

Provide more functions to CPU profiler (fix issue 858).

The cause for missing functions is that some of them are created
from compiled code (see FastNewClosureStub), and thus not get
registered in profiler's code map.

My solution is to hook on GC visitor to provide JS functions
addresses to profiler, only if it is enabled.

BUG=858
TEST=

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

[Vyacheslav Egorov (Chromium), 2010-09-23 15:48:32]

There is a change in scavenge but no changes in mark-sweep/compact. Is this
intentional?

[mnaganov (inactive), 2010-09-23 15:56:59]

On 2010/09/23 15:48:32, Vyacheslav Egorov wrote:
> There is a change in scavenge but no changes in mark-sweep/compact. Is this
> intentional?

FastNewClosureStub allocates in NewSpace. There is an option to allocate
functions in OldPointerSpace via Factory, but I believe I'm tracking all the
cases where functions get created this way explicitly. Don't want to add more
overhead.

[mnaganov (inactive), 2010-09-23 17:03:04]

On 2010/09/23 15:56:59, Michail Naganov wrote:
> On 2010/09/23 15:48:32, Vyacheslav Egorov wrote:
> > There is a change in scavenge but no changes in mark-sweep/compact. Is this
> > intentional?
> 
> FastNewClosureStub allocates in NewSpace. There is an option to allocate
> functions in OldPointerSpace via Factory, but I believe I'm tracking all the
> cases where functions get created this way explicitly. Don't want to add more
> overhead.

Thanks to Vyacheslav's explanations over IM, I see that I really need to hook on
MC/MS object moves. Will update patch soon.

[mnaganov (inactive), 2010-09-24 09:47:26]

On 2010/09/23 17:03:04, Michail Naganov wrote:
> On 2010/09/23 15:56:59, Michail Naganov wrote:
> > On 2010/09/23 15:48:32, Vyacheslav Egorov wrote:
> > > There is a change in scavenge but no changes in mark-sweep/compact. Is
this
> > > intentional?
> > 
> > FastNewClosureStub allocates in NewSpace. There is an option to allocate
> > functions in OldPointerSpace via Factory, but I believe I'm tracking all the
> > cases where functions get created this way explicitly. Don't want to add
more
> > overhead.
> 
> Thanks to Vyacheslav's explanations over IM, I see that I really need to hook
on
> MC/MS object moves. Will update patch soon.

Soeren, I uploaded the patch, please review.

[Søren Thygesen Gjesse, 2010-09-24 10:20:07]

LGTM

Will this only start profiling these functions after a full GC, or does the
processing of the events make it possible to trace the new function backwards to
when it was created and process ticks from that point?

http://codereview.chromium.org/3417019/diff/6001/7001
File src/cpu-profiler.cc (right):

http://codereview.chromium.org/3417019/diff/6001/7001#newcode431
src/cpu-profiler.cc:431: // The same function can be reported several times.
Please add a comment here that this is called during mark-compact where marking
bits might still be set.

http://codereview.chromium.org/3417019/diff/6001/7004
File src/log.cc (right):

http://codereview.chromium.org/3417019/diff/6001/7004#newcode879
src/log.cc:879: msg.Append(',');
I think a comment here on why we use unchecked_code would be helpful.

[mnaganov (inactive), 2010-09-24 11:43:40]

On 2010/09/24 10:20:07, Søren Gjesse wrote:
> LGTM
> 
> Will this only start profiling these functions after a full GC, or does the
> processing of the events make it possible to trace the new function backwards
to
> when it was created and process ticks from that point?
> 

I hooked on scavenge, so full GC isn't required. You are right, some samples can
still miss a function on decoding, but this should not last for a long time, as
scavenges do happen frequently.

http://codereview.chromium.org/3417019/diff/6001/7001
File src/cpu-profiler.cc (right):

http://codereview.chromium.org/3417019/diff/6001/7001#newcode431
src/cpu-profiler.cc:431: // The same function can be reported several times.
On 2010/09/24 10:20:07, Søren Gjesse wrote:
> Please add a comment here that this is called during mark-compact where
marking
> bits might still be set.

Done.

http://codereview.chromium.org/3417019/diff/6001/7004
File src/log.cc (right):

http://codereview.chromium.org/3417019/diff/6001/7004#newcode879
src/log.cc:879: msg.Append(',');
On 2010/09/24 10:20:07, Søren Gjesse wrote:
> I think a comment here on why we use unchecked_code would be helpful.

Done.

[Søren Thygesen Gjesse, 2010-09-24 12:01:04]

I missed the scavenge change in heap.cc.

On 2010/09/24 11:43:40, Michail Naganov wrote:
> On 2010/09/24 10:20:07, Søren Gjesse wrote:
> > LGTM
> > 
> > Will this only start profiling these functions after a full GC, or does the
> > processing of the events make it possible to trace the new function
backwards
> to
> > when it was created and process ticks from that point?
> > 
> 
> I hooked on scavenge, so full GC isn't required. You are right, some samples
can
> still miss a function on decoding, but this should not last for a long time,
as
> scavenges do happen frequently.
> 
> http://codereview.chromium.org/3417019/diff/6001/7001
> File src/cpu-profiler.cc (right):
> 
> http://codereview.chromium.org/3417019/diff/6001/7001#newcode431
> src/cpu-profiler.cc:431: // The same function can be reported several times.
> On 2010/09/24 10:20:07, Søren Gjesse wrote:
> > Please add a comment here that this is called during mark-compact where
> marking
> > bits might still be set.
> 
> Done.
> 
> http://codereview.chromium.org/3417019/diff/6001/7004
> File src/log.cc (right):
> 
> http://codereview.chromium.org/3417019/diff/6001/7004#newcode879
> src/log.cc:879: msg.Append(',');
> On 2010/09/24 10:20:07, Søren Gjesse wrote:
> > I think a comment here on why we use unchecked_code would be helpful.
> 
> Done.