Implement resource-saving mode of Profiler.

Implement resource-saving ("lazy") mode of Profiler.

This is intended to be used with Chromium. When in resource-saving mode, profiler doesn't consume any resources (sampler and logging is off) until resumed. Then again, when profiler is paused, sampling and logging are turned off.

Tested under Linux and Windows. Also have done preliminary testing with Chromium.

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

[William Hesse, 2009-05-22 11:10:04]

http://codereview.chromium.org/113762/diff/1/2
File src/flag-definitions.h (right):

http://codereview.chromium.org/113762/diff/1/2#newcode340
Line 340: "Log profiling data to memory buffer, memory-saving mode"
It is unclear how something that logs to memory can also save memory.  Is it
reducing the size of the ultimate log file?

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

http://codereview.chromium.org/113762/diff/1/6#newcode220
Line 220: 
Would it be possible to check that ticks are actually logged after profiling is
resumed?

[Mikhail Naganov, 2009-05-22 11:53:10]

http://codereview.chromium.org/113762/diff/1/2
File src/flag-definitions.h (right):

http://codereview.chromium.org/113762/diff/1/2#newcode340
Line 340: "Log profiling data to memory buffer, memory-saving mode"
On 2009/05/22 11:10:05, William Hesse wrote:
> It is unclear how something that logs to memory can also save memory.  Is it
> reducing the size of the ultimate log file?

Is "lazy" a good name? The intention behind this mode is that profiling is
enabled but doesn't consume resources (mem & cpu) until resumed.

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

http://codereview.chromium.org/113762/diff/1/6#newcode220
Line 220: 
On 2009/05/22 11:10:05, William Hesse wrote:
> Would it be possible to check that ticks are actually logged after profiling
is
> resumed?

Sure. Will add.

[Søren Thygesen Gjesse, 2009-05-25 07:09:15]

LGTM

http://codereview.chromium.org/113762/diff/25/1005
File src/flag-definitions.h (right):

http://codereview.chromium.org/113762/diff/25/1005#newcode338
Line 338: "Used with --prof, starts profiling automatically")
Do we need both --prof-auto and --prof-lazy. With your last change where logging
can be initiated by getting all the functions in the heap I don't see a reason
for logging and sampling if not really profiling. Am I missing something here?
If it makes sense to consolidate --prof-auto and --prof-lazy in some way you can
do that in a new change.

http://codereview.chromium.org/113762/diff/25/1006
File src/log.cc (right):

http://codereview.chromium.org/113762/diff/25/1006#newcode181
Line 181: if (!FLAG_prof_lazy && !IsActive()) Start();
I am not sure about this handling of the prof_lazy flag. The main reason for
implementing the sliding window average was to enable some display of it in
Chrome. This should be unrelated to dev tools - maybe in the task manager. This
is still not implemented, so I guess this is fine for now.

http://codereview.chromium.org/113762/diff/25/1009
File test/cctest/test-log.cc (right):

http://codereview.chromium.org/113762/diff/25/1009#newcode88
Line 88: template <typename T>
Why is this a template function? T needs to be char for Logger::GetLogLines to
match.

[Mikhail Naganov, 2009-05-25 08:23:43]

Thanks, Søren and William!

http://codereview.chromium.org/113762/diff/25/1005
File src/flag-definitions.h (right):

http://codereview.chromium.org/113762/diff/25/1005#newcode338
Line 338: "Used with --prof, starts profiling automatically")
On 2009/05/25 07:09:15, Søren Gjesse wrote:
> Do we need both --prof-auto and --prof-lazy. With your last change where
logging
> can be initiated by getting all the functions in the heap I don't see a reason
> for logging and sampling if not really profiling. Am I missing something here?
> If it makes sense to consolidate --prof-auto and --prof-lazy in some way you
can
> do that in a new change.

Currently, we have several differences in results of "traditional" compiler / gc
logging vs. heap traversal, the differences can be seen in the code of
"AreFuncNamesEqual" and "AreEntitiesEqual" functions from test-log.cc. They only
related to native and internal code, so they are irrelevant to web app
developers, but may make sense for V8 developers. That's why I'll prefer to
leave "traditional" profiling logging for some time until I figure out how to
handle this better.

http://codereview.chromium.org/113762/diff/25/1006
File src/log.cc (right):

http://codereview.chromium.org/113762/diff/25/1006#newcode181
Line 181: if (!FLAG_prof_lazy && !IsActive()) Start();
On 2009/05/25 07:09:15, Søren Gjesse wrote:
> I am not sure about this handling of the prof_lazy flag. The main reason for
> implementing the sliding window average was to enable some display of it in
> Chrome. This should be unrelated to dev tools - maybe in the task manager.
This
> is still not implemented, so I guess this is fine for now.

That's an important thing to know, thanks for noticing. I removed flag usage
from here, and also added checking of FLAG_sliding_state_window in
Pause/ResumeProfiler functions to avoid stopping/restarting Ticker when SSW is
enabled.

http://codereview.chromium.org/113762/diff/25/1009
File test/cctest/test-log.cc (right):

http://codereview.chromium.org/113762/diff/25/1009#newcode88
Line 88: template <typename T>
On 2009/05/25 07:09:15, Søren Gjesse wrote:
> Why is this a template function? T needs to be char for Logger::GetLogLines to
> match.

Yep, you're right. Fixed.