NOT FOR REVIEW - Slow Reports Reference Implementation

content/public/browser/background_tracing_manager.h

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_PUBLIC_BROWSER_BACKGROUND_TRACING_MANAGER_H_
+#define CONTENT_PUBLIC_BROWSER_BACKGROUND_TRACING_MANAGER_H_
+
+#include "base/memory/ref_counted_memory.h"
+#include "base/memory/scoped_ptr.h"
+#include "base/memory/weak_ptr.h"
+#include "base/trace_event/trace_event_impl.h"
+#include "base/values.h"
+#include "content/common/content_export.h"
+
+namespace content {
+
+class BackgroundTracingConfig :
+    public base::RefCountedThreadSafe<BackgroundTracingConfig> {
+ public:
+  enum Mode {
+    PREEMPTIVE_TRACING_MODE,
+    REACTIVE_TRACING_MODE,
+  };
+
+  enum CategoryPreset {
+    BENCHMARK,
+    BENCHMARK_DEEP,
+  };
+
+  BackgroundTracingConfig(Mode);
+
+  Mode mode;

[oystein (OOO til 10th of July), 2015/05/05 19:28:31]

private or in the impl maybe?

+
+  static bool FromDict(const base::DictionaryValue*);
+  void IntoDict(base::DictionaryValue*);

[oystein (OOO til 10th of July), 2015/05/05 19:28:31]

Are these the to/from JSON things? I don't remember the context.

[shatch, 2015/05/05 20:20:23]

Yep

+
+ protected:
+  friend class base::RefCountedThreadSafe<BackgroundTracingConfig>;
+  virtual ~BackgroundTracingConfig();
+};
+
+class BackgroundTracingPreemptiveConfig :
+    public BackgroundTracingConfig {
+ public:
+  BackgroundTracingPreemptiveConfig();
+
+  enum RuleType {
+    MONITOR_AND_DUMP_WHEN_TRIGGER_NAMED,
+    MONITOR_AND_DUMP_WHEN_SPECIFIC_HISTOGRAM_AND_VALUE,
+    MONITOR_AND_DUMP_WHEN_BROWSER_STARTED,
+  };
+  struct HistogramTriggerInfo {
+    std::string histogram_name_to_trigger_on;
+    int histogram_bin_to_trigger_on;
+  };
+  struct NamedTriggerInfo {
+    std::string trigger_name;
+  };
+  struct MonitoringRule {
+    RuleType type;
+    HistogramTriggerInfo histogram_trigger_info;
+    NamedTriggerInfo named_trigger_info;
+  };
+  std::vector<MonitoringRule> configs;

[shatch, 2015/05/05 18:50:21]

Anybody got any thoughts on these configs?

[oystein (OOO til 10th of July), 2015/05/05 19:28:31]

Hmm. Maybe this should just be how it's stored internally, and we just have a
way to add a single new rule in the public API, for each call? I could see these
coming from multiple sources; i.e. Finch could add rules, command-line switches
could add rules...

[shatch, 2015/05/05 20:20:23]

so something like:

class BackgroundTracingPreemptiveConfig {
 public:
  void AddHistogramTriggerRule(...);
  void AddNamedTriggerRule(...);
 private:
  ..stuff
}

Ditto for ReactiveConfig?

[oystein (OOO til 10th of July), 2015/05/05 20:40:10]

I was thinking more that the config class which gets passed to AddScenario (or
RegisterScenario or whatever is better) just contains stuff for a single rule,
rather than all of them. I don't think there was any particular reason to just
be able to set the entire thing at once, but maybe I'm forgetting something.

+  CategoryPreset category_preset;
+
+  static bool FromDict(const base::DictionaryValue*);
+  void IntoDict(base::DictionaryValue*);
+
+ protected:
+  ~BackgroundTracingPreemptiveConfig() override;
+};
+
+class BackgroundTracingReactiveConfig :
+    public BackgroundTracingConfig {
+ public:
+  BackgroundTracingReactiveConfig();
+
+  enum RuleType {
+    TRACE_ON_TRIGGER_UNTIL_10S_OR_NEXT_TRIGGER_OR_FULL
+  };
+  struct TracingRule {
+    RuleType type;
+    std::string trigger_name;
+    CategoryPreset category_preset;
+  };
+  std::vector<TracingRule> configs;
+
+  static bool FromDict(const base::DictionaryValue*);
+  void IntoDict(base::DictionaryValue*);
+
+ protected:
+  ~BackgroundTracingReactiveConfig() override;
+};
+
+
+// BackgroundTracingManager is used on the browser process to trigger the
+// collection of trace data and upload the results. Only the browser UI thread
+// is allowed to interact with the BackgroundTracingManager. All callbacks are
+// called on the UI thread.
+class BackgroundTracingManager {
+ public:
+  CONTENT_EXPORT static BackgroundTracingManager* GetInstance();
+
+  // Interface for trace data consumer. An implemnentation of this interface
+  // is passed to SetActiveScenario() and receives the trace data.
+  // This may happen on any thread.
+  class UploadSink :

[shatch, 2015/05/05 18:50:21]

I moved this in here, should we just leave it out in the content namespace as
BackgroundTracingUploadSink?

[oystein (OOO til 10th of July), 2015/05/05 19:28:31]

Or maybe even just TracingUploadSink; they aren't really specific to background
tracing.

[shatch, 2015/05/05 20:20:23]

I guess, but who else might use it? Kinda feels we should keep it as
BackgroundTracingUploadSink since that's the pattern here.

[oystein (OOO til 10th of July), 2015/05/05 20:40:10]

True enough.

+      public base::RefCountedThreadSafe<UploadSink> {
+   public:
+    virtual void Upload(const std::string&, base::Callback<void()>) = 0;
+    virtual bool RequiresAnonymizedData() const = 0;
+
+   protected:
+    friend class base::RefCountedThreadSafe<UploadSink>;
+    virtual ~UploadSink() {}
+  };
+
+  virtual bool SetActiveScenario(
+      scoped_refptr<BackgroundTracingConfig>,
+      scoped_refptr<UploadSink>) = 0;
+
+  typedef base::Callback<void()> IdleCallback;
+  virtual void WhenIdle(IdleCallback idle_callback) = 0;
+
+  typedef base::Callback<void(bool)> StartedFinalizingCallback;
+  typedef size_t TriggerHandle;
+
+  virtual void DidTriggerHappen(TriggerHandle, StartedFinalizingCallback) = 0;
+  virtual TriggerHandle RegisterTriggerType(const char* trigger_name) = 0;
+  virtual void GetTriggerNameList(std::vector<std::string>& trigger_names) = 0;
+  virtual void InvalidateTriggerHandlesForTesting() = 0;
+
+ protected:
+  virtual ~BackgroundTracingManager() {}
+};
+
+} // namespace content
+
+#endif  // CONTENT_PUBLIC_BROWSER_BACKGROUND_TRACING_MANAGER_H_