Fix issue 571: display descriptive names for code objects from snapshot.

Fix issue 571: display descriptive names for code objects from snapshot.

As this is only needed for internal profiling (not for DevTools),
the following approach had been chosen:

 - during snapshot creation, positions of serialized objects inside
   a snapshot are logged;

 - then during V8 initialization, positions of deserealized objects
   are logged;

 - those positions are used for retrieving code objects names from
   snapshot creation log, which needs to be supplied to tick processor
   script.

Positions logging is controlled with the new flag: --log_snapshot_positions.
This flag is turned off by default, and this adds no startup penalty.

To plug this fix to Golem, the following actions are needed:
 
 - logs created using 'mksnapshot' need to be stored along with VM images;

 - tick processor script needs to be run with '--snapshot-log=...' cmdline
   argument.

BUG=571
Committed: http://code.google.com/p/v8/source/detail?r=3635

[Erik Corry, 2010-01-18 15:43:34]

LGTM.  The python version should probably be taught to ignore the new info if it
doesn't already do that.

[Erik Corry, 2010-01-18 15:47:51]

Just one thing:

http://codereview.chromium.org/551062/diff/1/7
File src/serialize.cc (right):

http://codereview.chromium.org/551062/diff/1/7#newcode700
src/serialize.cc:700: LOG(SnapshotPositionEvent(address, source_->position()));
Putting this in an if (FLAG_log_snapshot_positions) would avoid the call, but if
you can't see the difference in benchmarks I guess it's not necessary.

[mnaganov (inactive), 2010-01-18 16:07:03]

On 2010/01/18 15:47:51, Erik Corry wrote:
> Just one thing:
> 
> http://codereview.chromium.org/551062/diff/1/7
> File src/serialize.cc (right):
> 
> http://codereview.chromium.org/551062/diff/1/7#newcode700
> src/serialize.cc:700: LOG(SnapshotPositionEvent(address,
source_->position()));
> Putting this in an if (FLAG_log_snapshot_positions) would avoid the call, but
if
> you can't see the difference in benchmarks I guess it's not necessary.

Fixed to be on a safe side.


As for Python version: those records are only emitted by a request (when flag is
specified), so if one still uses Python version, he just should not set this
flag.