i#359 -prof_pcs asserts: support multi-threading and long JIT runs

Commit log for first patchset:
---------------
i#359 -prof_pcs asserts: support multi-threading and long JIT runs

Releases the shared_itimer lock early for ITIMER_VIRTUAL so the
profiler can acquire other locks while collecting data. Adds an
option to specify the profiler's special heap size for targets
that generate unusually large numbers of unique sample pcs. Adds
a test for -prof_pcs with a multi-threaded target.

Fixes #359
---------------

[Byron, 2015-12-09 22:54:27]

https://codereview.appspot.com/277280043/diff/1/core/unix/signal.c
File core/unix/signal.c (right):

https://codereview.appspot.com/277280043/diff/1/core/unix/signal.c#newcode5750
core/unix/signal.c:5750: if (which == ITIMER_VIRTUAL && info->shared_itimer &&
should_release_lock) {
Could the early lock release affect clients using ITIMER_VIRTUAL?

[bruening, 2015-12-10 04:53:18]

LGTM w/ comment

https://codereview.appspot.com/277280043/diff/1/core/heap.c
File core/heap.c (right):

https://codereview.appspot.com/277280043/diff/1/core/heap.c#newcode4522
core/heap.c:4522: bool special_heap_can_calloc(void *special, uint num)
style violation: bool own own line

https://codereview.appspot.com/277280043/diff/1/core/unix/signal.c
File core/unix/signal.c (right):

https://codereview.appspot.com/277280043/diff/1/core/unix/signal.c#newcode5750
core/unix/signal.c:5750: if (which == ITIMER_VIRTUAL && info->shared_itimer &&
should_release_lock) {
On 2015/12/09 22:54:27, Byron wrote:
> Could the early lock release affect clients using ITIMER_VIRTUAL?

An alarm interrupting a thread making an itimer syscall: already murky and
attempted to be handled above if can't get lock by continuing, so now we would
just continue anyway.

An alarm interrupting a prior alarm's cb: similar.

https://codereview.appspot.com/277280043/diff/1/suite/tests/CMakeLists.txt
File suite/tests/CMakeLists.txt (right):

https://codereview.appspot.com/277280043/diff/1/suite/tests/CMakeLists.txt#ne...
suite/tests/CMakeLists.txt:1717: "annotation-concurrency.prof-pcs")
Is the output identical to existing tests?  If so can we avoid a new template
file?

[Byron, 2015-12-10 08:37:55]

Committed as
https://github.com/DynamoRIO/dynamorio/commit/2683ba52ba95babfb678ff492b994ec...

Final commit log: 
---------------
i#359 -prof_pcs asserts: support multi-threading and long JIT runs

Releases the shared_itimer lock early for ITIMER_VIRTUAL so the
profiler can acquire other locks while collecting data. Adds an
option to specify the profiler's special heap size for targets
that generate unusually large numbers of unique sample pcs. Adds
a test for -prof_pcs with a multi-threaded target.

Fixes #359

Review-URL: https://codereview.appspot.com/277280043
---------------

[Byron, 2015-12-10 08:40:38]

https://codereview.appspot.com/277280043/diff/1/core/heap.c
File core/heap.c (right):

https://codereview.appspot.com/277280043/diff/1/core/heap.c#newcode4522
core/heap.c:4522: bool special_heap_can_calloc(void *special, uint num)
On 2015/12/10 04:53:18, bruening wrote:
> style violation: bool own own line

Done.

https://codereview.appspot.com/277280043/diff/1/core/unix/signal.c
File core/unix/signal.c (right):

https://codereview.appspot.com/277280043/diff/1/core/unix/signal.c#newcode5750
core/unix/signal.c:5750: if (which == ITIMER_VIRTUAL && info->shared_itimer &&
should_release_lock) {
On 2015/12/10 04:53:18, bruening wrote:
> On 2015/12/09 22:54:27, Byron wrote:
> > Could the early lock release affect clients using ITIMER_VIRTUAL?
> 
> An alarm interrupting a thread making an itimer syscall: already murky and
> attempted to be handled above if can't get lock by continuing, so now we would
> just continue anyway.
> 
> An alarm interrupting a prior alarm's cb: similar.

Acknowledged.

https://codereview.appspot.com/277280043/diff/1/suite/tests/CMakeLists.txt
File suite/tests/CMakeLists.txt (right):

https://codereview.appspot.com/277280043/diff/1/suite/tests/CMakeLists.txt#ne...
suite/tests/CMakeLists.txt:1717: "annotation-concurrency.prof-pcs")
On 2015/12/10 04:53:18, bruening wrote:
> Is the output identical to existing tests?  If so can we avoid a new template
> file?

Unfortunately the output is very different because this is the only annotation
test instance without a client. When client+pcprof is fixed, we can remove the
added template.