Make CPU profiler do not hog 100% of CPU.

Make CPU profiler do not hog 100% of CPU.

Tick event processor should not stay in a tight loop
when there's nothing to do. It can go sleep until next sample event.

LOG=N
BUG=v8:3967
Committed: https://crrev.com/6964a9e0685fa186d9d9b7907be17505e839db1a
Cr-Commit-Position: refs/heads/master@{#28211}

[alph, 2015-04-29 15:23:42]

The CQ bit was checked by alph@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-04-29 15:23:47]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1118533003/1

[alph, 2015-04-29 15:28:00]

alph@chromium.org changed reviewers:
+ bmeurer@chromium.org, svenpanne@chromium.org, yurys@chromium.org

[alph, 2015-04-29 15:28:01]

Folks, please take a look. Thanks.

[commit-bot: I haz the power, 2015-04-29 15:57:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-04-29 15:57:37]

Dry run: This issue passed the CQ dry run.

[alph, 2015-04-29 18:57:19]

The CQ bit was checked by alph@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-04-29 18:57:33]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1118533003/20001

[commit-bot: I haz the power, 2015-04-29 19:35:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-04-29 19:35:46]

Dry run: This issue passed the CQ dry run.

[Benedikt Meurer, 2015-04-30 05:06:01]

https://codereview.chromium.org/1118533003/diff/20001/src/cpu-profiler.cc
File src/cpu-profiler.cc (right):

https://codereview.chromium.org/1118533003/diff/20001/src/cpu-profiler.cc#new...
src/cpu-profiler.cc:140: #if V8_OS_WIN
I don't really like this special casing for Windows here. Is there no
alternative to Sleep on Windows which would work for our purpose?

[yurys, 2015-04-30 08:10:02]

https://codereview.chromium.org/1118533003/diff/20001/src/cpu-profiler.cc
File src/cpu-profiler.cc (right):

https://codereview.chromium.org/1118533003/diff/20001/src/cpu-profiler.cc#new...
src/cpu-profiler.cc:140: #if V8_OS_WIN
On 2015/04/30 05:06:01, Benedikt Meurer wrote:
> I don't really like this special casing for Windows here. Is there no
> alternative to Sleep on Windows which would work for our purpose?

Would "Multimedia Timers" work here?

[alph, 2015-04-30 10:13:34]

https://codereview.chromium.org/1118533003/diff/20001/src/cpu-profiler.cc
File src/cpu-profiler.cc (right):

https://codereview.chromium.org/1118533003/diff/20001/src/cpu-profiler.cc#new...
src/cpu-profiler.cc:140: #if V8_OS_WIN
On 2015/04/30 05:06:01, Benedikt Meurer wrote:
> I don't really like this special casing for Windows here. Is there no
> alternative to Sleep on Windows which would work for our purpose?

I'm not aware of such method. I appreciate if you can suggest something.
AFAIK this is a fundamental windows thread scheduler property. There's a
possibility to decrease scheduler time slice down to 1ms, but this is still too
much for our purposes.

https://codereview.chromium.org/1118533003/diff/20001/src/cpu-profiler.cc#new...
src/cpu-profiler.cc:140: #if V8_OS_WIN
On 2015/04/30 08:10:02, yurys wrote:
> On 2015/04/30 05:06:01, Benedikt Meurer wrote:
> > I don't really like this special casing for Windows here. Is there no
> > alternative to Sleep on Windows which would work for our purpose?
> 
> Would "Multimedia Timers" work here?

They have 1ms resolution at best which is still not enough for us.

[noordhuis, 2015-04-30 10:15:07]

Just a suggestion but sem_post() is async signal-safe; it can wake up the event
processor thread on-demand from the SIGPROF signal handler.  That's arguably a
little neater than sleeping for arbitrary periods.

[alph, 2015-04-30 10:27:53]

On 2015/04/30 10:15:07, noordhuis wrote:
> Just a suggestion but sem_post() is async signal-safe; it can wake up the
event
> processor thread on-demand from the SIGPROF signal handler.  That's arguably a
> little neater than sleeping for arbitrary periods.

Using profile timer is a bit orthogonal to the problem we're trying to solve
here.
Currently the "processor" thread is used for both tasks:
1. process sample and code ticks from the buffers
2. fire sample events.
It is possible to extract firing of sample events and use profile timer instead.

[noordhuis, 2015-04-30 10:45:07]

On 2015/04/30 10:27:53, alph wrote:
> On 2015/04/30 10:15:07, noordhuis wrote:
> > Just a suggestion but sem_post() is async signal-safe; it can wake up the
> event
> > processor thread on-demand from the SIGPROF signal handler.  That's arguably
a
> > little neater than sleeping for arbitrary periods.
> 
> Using profile timer is a bit orthogonal to the problem we're trying to solve
> here.
> Currently the "processor" thread is used for both tasks:
> 1. process sample and code ticks from the buffers
> 2. fire sample events.
> It is possible to extract firing of sample events and use profile timer
instead.

You mean setitimer(ITIMER_PROF)?  I've wondered in the past why V8 uses a thread
instead of a timer.  Threads are frequently much more jittery than timers.

[yurys, 2015-04-30 11:53:20]

lgtm, looks like there is no better option for Windows.

On 2015/04/30 10:13:34, alph wrote:
> https://codereview.chromium.org/1118533003/diff/20001/src/cpu-profiler.cc
> File src/cpu-profiler.cc (right):
> 
>
https://codereview.chromium.org/1118533003/diff/20001/src/cpu-profiler.cc#new...
> src/cpu-profiler.cc:140: #if V8_OS_WIN
> On 2015/04/30 05:06:01, Benedikt Meurer wrote:
> > I don't really like this special casing for Windows here. Is there no
> > alternative to Sleep on Windows which would work for our purpose?
> 
> I'm not aware of such method. I appreciate if you can suggest something.
> AFAIK this is a fundamental windows thread scheduler property. There's a
> possibility to decrease scheduler time slice down to 1ms, but this is still
too
> much for our purposes.
> 
>
https://codereview.chromium.org/1118533003/diff/20001/src/cpu-profiler.cc#new...
> src/cpu-profiler.cc:140: #if V8_OS_WIN
> On 2015/04/30 08:10:02, yurys wrote:
> > On 2015/04/30 05:06:01, Benedikt Meurer wrote:
> > > I don't really like this special casing for Windows here. Is there no
> > > alternative to Sleep on Windows which would work for our purpose?
> > 
> > Would "Multimedia Timers" work here?
> 
> They have 1ms resolution at best which is still not enough for us.

[alph, 2015-04-30 12:02:08]

On 2015/04/30 10:45:07, noordhuis wrote:
> On 2015/04/30 10:27:53, alph wrote:
> > On 2015/04/30 10:15:07, noordhuis wrote:
> > > Just a suggestion but sem_post() is async signal-safe; it can wake up the
> > event
> > > processor thread on-demand from the SIGPROF signal handler.  That's
arguably
> a
> > > little neater than sleeping for arbitrary periods.
> > 
> > Using profile timer is a bit orthogonal to the problem we're trying to solve
> > here.
> > Currently the "processor" thread is used for both tasks:
> > 1. process sample and code ticks from the buffers
> > 2. fire sample events.
> > It is possible to extract firing of sample events and use profile timer
> instead.
> 
> You mean setitimer(ITIMER_PROF)?  I've wondered in the past why V8 uses a
thread
> instead of a timer.  Threads are frequently much more jittery than timers.

Yes, that's what I meant.
We can (and probably will) change it to ITIMER_PROF, but it won't help Windows.

[Benedikt Meurer, 2015-05-04 04:55:28]

lgtm

[alph, 2015-05-04 06:49:23]

The CQ bit was checked by alph@chromium.org

[commit-bot: I haz the power, 2015-05-04 06:49:35]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1118533003/20001

[commit-bot: I haz the power, 2015-05-04 06:50:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-05-04 06:50:59]

Try jobs failed on following builders:
  v8_linux64_avx2_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel/builds/63)
  v8_linux_arm64_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel/builds/5379)

[alph, 2015-05-04 21:46:56]

The CQ bit was checked by alph@chromium.org

[alph, 2015-05-04 21:46:57]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, yurys@chromium.org
Link to the patchset: https://codereview.chromium.org/1118533003/#ps100001
(title: "still uploading")

[commit-bot: I haz the power, 2015-05-04 21:47:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1118533003/100001

[commit-bot: I haz the power, 2015-05-04 22:53:34]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-05-04 22:53:46]

Patchset 6 (id:??) landed as
https://crrev.com/6964a9e0685fa186d9d9b7907be17505e839db1a
Cr-Commit-Position: refs/heads/master@{#28211}