Reduce CPU usage when no isolates need to be profiled.

Reduce CPU usage when no isolates need to be profiled (e.g. when an isolate calls readLineSync or sleep the isolate owns the thread but is blocked).

This CL does the following:

- Introduces two new API entry points: Dart_IsolateBlocked and Dart_IsolateUnblocked.
- The thread interrupter thread goes into a deep sleep if no isolates need to be profiled (not scheduled on a thread or are in a blocking call).
- When an isolate unblocks, the thread interrupter thread resumes regular interrupts.
- dart:io readLineSync and sleep mark that they are making a blocking call.

This fixes https://code.google.com/p/dart/issues/detail?id=18126 reducing CPU usage to 0% when waiting for stdin or sleeping.

R=ajohnsen@google.com, iposva@google.com

Committed: https://code.google.com/p/dart/source/detail?r=36632

[Cutch, 2014-05-24 09:02:03]

+ajohnsen for the dart:io bits.

[Ivan Posva, 2014-05-25 12:25:16]

https://codereview.chromium.org/297183003/diff/40001/runtime/include/dart_api.h
File runtime/include/dart_api.h (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/include/dart_api...
runtime/include/dart_api.h:2637: DART_EXPORT void Dart_BlockProfiler();
This is not just related to the profiler. What we want is to signal the VM that
this isolate is making a blocking call. => Dart_IsolateBlocked,
Dart_IsolateUnblocked

The profiler then certainly can key off of this information, but there might be
other areas that could use this signal.

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/isolate.cc
File runtime/vm/isolate.cc (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/isolate.cc#ne...
runtime/vm/isolate.cc:1007: intptr_t Isolate::ProfileInterrupt() {
What other values besides true/false do you expect here?

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/profiler.cc
File runtime/vm/profiler.cc (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/profiler.cc#n...
runtime/vm/profiler.cc:1607: block_count_--;
ASSERT that you are not over unblocking.

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/thread_interr...
File runtime/vm/thread_interrupter.cc (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/thread_interr...
runtime/vm/thread_interrupter.cc:104: shutdown_ml.Wait();
Aren't you waiting on your own notification in this case?

Why do we need to wait for the thread_running_ to change? Since below we are
joining with the thread anyway.

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/thread_interr...
runtime/vm/thread_interrupter.cc:299: current_wait_time_ = 0;
Please add a comment that a wait time of 0 means indefinitely.

[Anders Johnsen, 2014-05-25 18:36:34]

lgtm

lgtm

https://codereview.chromium.org/297183003/diff/40001/runtime/bin/utils.h
File runtime/bin/utils.h (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/bin/utils.h#newc...
runtime/bin/utils.h:92: class ProfilerBlocker {
Stuff like this usually go into dartutils.h.

https://codereview.chromium.org/297183003/diff/40001/runtime/include/dart_api.h
File runtime/include/dart_api.h (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/include/dart_api...
runtime/include/dart_api.h:2637: DART_EXPORT void Dart_BlockProfiler();
On 2014/05/25 12:25:16, Ivan Posva wrote:
> This is not just related to the profiler. What we want is to signal the VM
that
> this isolate is making a blocking call. => Dart_IsolateBlocked,
> Dart_IsolateUnblocked
> 
> The profiler then certainly can key off of this information, but there might
be
> other areas that could use this signal.

+1, I like the more generic IsolateBlocked/IsolateUnblocked.

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/isolate.cc
File runtime/vm/isolate.cc (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/isolate.cc#ne...
runtime/vm/isolate.cc:1010: return 0;
These should probably be enum values, if more than 2 values can be returned.

[Ivan Posva, 2014-05-25 19:07:47]

-Ivan

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/thread_interr...
File runtime/vm/thread_interrupter.cc (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/thread_interr...
runtime/vm/thread_interrupter.cc:248: profiled_isolate_count_ +=
isolate->ProfileInterrupt();
Please add a comment in ProfileInterrupt that the result value should contain
how many threads had their stacks sampled as part of the interrupt.

[Cutch, 2014-05-26 06:59:34]

https://codereview.chromium.org/297183003/diff/40001/runtime/bin/utils.h
File runtime/bin/utils.h (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/bin/utils.h#newc...
runtime/bin/utils.h:92: class ProfilerBlocker {
On 2014/05/25 18:36:34, Anders Johnsen wrote:
> Stuff like this usually go into dartutils.h.

Done and renamed to ScopedBlockingCall

https://codereview.chromium.org/297183003/diff/40001/runtime/include/dart_api.h
File runtime/include/dart_api.h (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/include/dart_api...
runtime/include/dart_api.h:2637: DART_EXPORT void Dart_BlockProfiler();
On 2014/05/25 12:25:16, Ivan Posva wrote:
> This is not just related to the profiler. What we want is to signal the VM
that
> this isolate is making a blocking call. => Dart_IsolateBlocked,
> Dart_IsolateUnblocked
> 
> The profiler then certainly can key off of this information, but there might
be
> other areas that could use this signal.

Done.

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/isolate.cc
File runtime/vm/isolate.cc (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/isolate.cc#ne...
runtime/vm/isolate.cc:1007: intptr_t Isolate::ProfileInterrupt() {
On 2014/05/25 12:25:16, Ivan Posva wrote:
> What other values besides true/false do you expect here?

I've switched this to return true / false.

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/profiler.cc
File runtime/vm/profiler.cc (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/profiler.cc#n...
runtime/vm/profiler.cc:1607: block_count_--;
On 2014/05/25 12:25:16, Ivan Posva wrote:
> ASSERT that you are not over unblocking.

Added a FATAL.

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/thread_interr...
File runtime/vm/thread_interrupter.cc (right):

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/thread_interr...
runtime/vm/thread_interrupter.cc:104: shutdown_ml.Wait();
On 2014/05/25 12:25:16, Ivan Posva wrote:
> Aren't you waiting on your own notification in this case?
> 

Moved the Notify out of the loop and replaced it with a call to WakeUp.

> Why do we need to wait for the thread_running_ to change? Since below we are
> joining with the thread anyway.

We only join the thread on Windows (pthreads we create DETACHED).

https://codereview.chromium.org/297183003/diff/40001/runtime/vm/thread_interr...
runtime/vm/thread_interrupter.cc:299: current_wait_time_ = 0;
On 2014/05/25 12:25:16, Ivan Posva wrote:
> Please add a comment that a wait time of 0 means indefinitely.

Switched to using Monitor::kNoTimeout which should be clear.

[Ivan Posva, 2014-05-26 07:38:44]

https://codereview.chromium.org/297183003/diff/90001/runtime/vm/thread_interr...
File runtime/vm/thread_interrupter.cc (right):

https://codereview.chromium.org/297183003/diff/90001/runtime/vm/thread_interr...
runtime/vm/thread_interrupter.cc:246: if (isolate->ProfileInterrupt()) {
If ProfileInterrupt returned the number of interrupted threads, then you could
just add them here. My comments in this area before were meant to ask for a
clarification in the ProfileInterrupt method.

[Cutch, 2014-05-26 08:23:33]

PTAL

https://codereview.chromium.org/297183003/diff/90001/runtime/vm/thread_interr...
File runtime/vm/thread_interrupter.cc (right):

https://codereview.chromium.org/297183003/diff/90001/runtime/vm/thread_interr...
runtime/vm/thread_interrupter.cc:246: if (isolate->ProfileInterrupt()) {
On 2014/05/26 07:38:45, Ivan Posva wrote:
> If ProfileInterrupt returned the number of interrupted threads, then you could
> just add them here. My comments in this area before were meant to ask for a
> clarification in the ProfileInterrupt method.

Back to intptr_t and added a comment on ProfileInterrupt about the return value.

[Ivan Posva, 2014-05-26 08:25:22]

LGTM -ip

[Cutch, 2014-05-26 11:54:13]

Committed patchset #9 manually as r36632 (presubmit successful).