[profiler] Implement POC Sampling Heap Profiler

include/v8-profiler.h

Index: include/v8-profiler.h
diff --git a/include/v8-profiler.h b/include/v8-profiler.h
index e432600290c6bb3e6749e7836b916eb5e0315e17..34f6447e60311bae6cb3d7deeca237f18030d36a 100644
--- a/include/v8-profiler.h
+++ b/include/v8-profiler.h
@@ -522,6 +522,44 @@ class V8_EXPORT HeapProfiler {
   void StopTrackingHeapObjects();
 
   /**
+   * Starts gathering a sampling heap profile. A sampling heap profile is
+   * similar to tcmalloc's heap profiler and Go's mprof. It samples object
+   * allocations and builds an online 'sampling' heap profile. At any point in
+   * time, this profile is expected to be a representative sample of objects
+   * currently live in the system. Each sampled allocation includes the stack

[Yang, 2016/01/07 06:14:10]

Not questioning the effectiveness, just curious: can we really consider it a
representative sample of live objects if we only observe allocation, but not
death of objects?

[ofrobots, 2016/01/07 06:49:30]

We do observe death as well. We keep a weak reference the the sampled object. At
any point in time the 'set of samples' is the set of objects we have sampled
that is still alive. Do you think the comment here is misleading? I can fix it
if that's the case.

[jochen (gone - plz use gerrit), 2016/01/07 10:29:34]

note that it's not possible to create weak references to all objects:
https://bugs.chromium.org/p/v8/issues/detail?id=3647

+   * trace at the time of allocation, which makes this really useful for memory
+   * leak detection.
+   *
+   * This mechanism is intended to be cheap enough that it can be used in
+   * production with minimal performance overhead.
+   *
+   * Allocations are sampled using a randomized Poisson process. On average, one
+   * allocation will be sampled every |sample_interval| bytes allocated. The
+   * |stack_depth| parameter controls the maximum number of stack frames to be
+   * captured on each allocation.
+   *
+   * NOTE: This is a proof-of-concept at this point. Right now we only sample
+   * newspace allocations. Support for paged space allocation (e.g. pre-tenured
+   * objects, large objects, code objects, etc.) and native allocations
+   * doesn't exist yet, but is anticipated in the future.
+   *
+   * Returns false if a sampling heap profiler is already running.
+   */
+  bool StartSamplingHeapProfiler(uint64_t sample_interval = 512 * 1024,
+                                 int stack_depth = 16);
+
+  /**
+   * Stops the sampling heap profile and discards the current profile.
+   */
+  void StopSamplingHeapProfiler();
+
+  /**
+   * Returns the set of currently live sampled allocations as a JSON string in
+   * the stream.
+   */
+  void GetHeapSample(OutputStream* stream);

[Yang, 2016/01/07 06:14:10]

I wonder whether it makes better sense to use the same format as the heap
snapshot uses. You can still turn it into JSON in post-processing. That way, we
could use it in devtools as well, as sort of light-weight heap snapshot that can
be always-on whenever devtools is active.

[ofrobots, 2016/01/07 06:49:30]

One of the difference is that heap-snapshot gives you the object graph, whereas
the sampling heap profiler gives you list of allocations currently live along
with the allocation stack trace. It does not give you the connections between
the objects (which a sampling of the objects cannot do).

I chose the present format (JSON string pushed to an OutputStream) to make it
similar to AllocationTracker as conceptually the SamplingHeapProfiler is closer
to AllocationTracker.

+
+  /**
    * Deletes all snapshots taken. All previously returned pointers to
    * snapshots and their contents become invalid after this call.
    */