No need to pass profiles to ProfilerEventsProcessor.

Following up on https://codereview.chromium.org/18353002, there's
no need to pass the profiles to ProfilerEventsProcessor's constructor.

BUG=
R=danno@chromium.org

Review URL: https://codereview.chromium.org/18332004

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@15413 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Plug leaked mutexes in OptimizingCompilerThread.

BUG=
R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/18345004

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@15414 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Test that profiler is stopped when isolate is being disposed

The only way to get v8::CpuProfiler instance in the V8 public API is to call v8::Iolate::GetCpuProfiler(). The method will return NULL if the isolate has not been initialized yet or has been torn down already. It is the client's reponsibility to make sure that CPU profiling has been stopped before disposing of the isolate.

This CL adds a test for this and several ASSRTS enforcing that assumptions. This allowed to be sure that heap is always setup when CPU profiling is being started. Based on that the number of places where already compiled functions are reported to the profiler event processor boils down to the single place (CpuProfiler::StartProcessorIfNotStarted). I'm going to rely on this assumption in further changes.

BUG=None
R=loislo@chromium.org, yangguo@chromium.org

Review URL: https://codereview.chromium.org/18336002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@15415 ce2b1a6d-e550-0410-aec6-3dcde31c8c00