CPU profiler: increase the max number of captured frames.

CPU profiler: increase the max number of captured frames.

LOG=N
R=jkummerow@chromium.org, loislo@chromium.org, yurys@chromium.org

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

[loislo, 2014-06-24 13:09:21]

lgtm with nits

https://codereview.chromium.org/357443003/diff/1/src/sampler.h
File src/sampler.h (right):

https://codereview.chromium.org/357443003/diff/1/src/sampler.h#newcode48
src/sampler.h:48: static const unsigned kMaxFramesCount = (1 <<
kMaxFramesCountLog2) - 1;
why do you have -1 here?

[alph, 2014-06-24 13:21:54]

Jacob could you please do the owners review. Thanks.

https://codereview.chromium.org/357443003/diff/1/src/sampler.h
File src/sampler.h (right):

https://codereview.chromium.org/357443003/diff/1/src/sampler.h#newcode48
src/sampler.h:48: static const unsigned kMaxFramesCount = (1 <<
kMaxFramesCountLog2) - 1;
On 2014/06/24 13:09:21, loislo wrote:
> why do you have -1 here?

the max value that can be stored in frames_count is 255 which is 2^8-1

[yurys, 2014-06-24 13:26:07]

lgtm

[Jakob Kummerow, 2014-06-24 13:54:38]

LGTM with comment.

https://codereview.chromium.org/357443003/diff/1/src/sampler.h
File src/sampler.h (right):

https://codereview.chromium.org/357443003/diff/1/src/sampler.h#newcode51
src/sampler.h:51: unsigned frames_count : kMaxFramesCountLog2;  // Number of
captured frames.
I'm not sure this will work. IIRC we've had an issue before where MSVS insisted
on sign-extending a packed value when reading it back out, but I'm not sure if
the circumstances were identical. If this fails on Windows (can you test locally
before landing?), this would be something to take a closer look at.

[alph, 2014-06-24 14:10:24]

https://codereview.chromium.org/357443003/diff/1/src/sampler.h
File src/sampler.h (right):

https://codereview.chromium.org/357443003/diff/1/src/sampler.h#newcode51
src/sampler.h:51: unsigned frames_count : kMaxFramesCountLog2;  // Number of
captured frames.
On 2014/06/24 13:54:37, Jakob wrote:
> I'm not sure this will work. IIRC we've had an issue before where MSVS
insisted
> on sign-extending a packed value when reading it back out, but I'm not sure if
> the circumstances were identical. If this fails on Windows (can you test
locally
> before landing?), this would be something to take a closer look at.

MSVC is noisy about implicit signed/unsigned conversions. But I seem to have all
of them fixed. I've run the try jobs.

Alternatively, I can add an extra bit here and keep it signed int if you like.

[Jakob Kummerow, 2014-06-24 15:27:41]

lgtm

[alph, 2014-06-24 16:01:05]

Committed patchset #3 manually as r21986.