Add GenericSharedMemoryId and use w/ GpuMemoryBuffer

ui/gfx/generic_shared_memory_tracing_id.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 UI_GFX_GENERIC_SHARED_MEMORY_TRACING_ID_H_
+#define UI_GFX_GENERIC_SHARED_MEMORY_TRACING_ID_H_
+
+#include "base/trace_event/memory_allocator_dump.h"
+#include "ui/gfx/gfx_export.h"
+
+namespace gfx {

[reveman, 2015/08/13 08:24:44]

This is OK but FYI, I was hoping to use this for discardable shared memory but
that's not really appropriate now that this lives in ui/gfx/. I guess I'll just
move it to base/ as part of changing discardable.

[danakj, 2015/08/13 17:29:50]

Yep. We can move it when we need it.

+
+// Defines an ID type which is used across all types of shared memory
+// allocations in content/. This ID type is in ui/gfx, as components outside
+// content/ may need to hold an ID (but should not generate one).
+class GFX_EXPORT GenericSharedMemoryTracingId {

[reveman, 2015/08/13 08:24:44]

What are some examples of usage that we're trying to protect against by making
this a class? How is it different from tracing_process_id, child_process_id,
client_id, discardable_memory_id, etc. that are just simple typedefs?

[danakj, 2015/08/13 17:29:50]

This was my idea. If we're going to use a typedef we're trying to name the
thing, but given these are being passed around amongst many different systems,
it seems easy to mix up ids/ints somewhere and pass the wrong thing. And you
wouldn't really know cuz it would just show different data in tracing. This
gives us some nice type safety.

[reveman, 2015/08/13 20:12:23]

We would see a difference. We'd not render anything and most likely crash if GMB
ids are messed up. Tracing will be the least of our concerns if the ids are not
correct. While some type safety is nice and I'm not against that, I'm still
struggling to see the difference and the need here compared to other ids. If
this is now what we prefer for all type of ids then I'd understand. I guess my
concern is that people will have trouble understanding why this is different
than other ids. An example where this class helps us would be useful for me to
understand.

[danakj, 2015/08/13 21:20:26]

Most ids are a part of a single small system. This was proposed as a very
general thing used all over the place. So my level of caution went up. If you're
going to put something in a very general place like base (or even ui/gfx),
people will (mis)use it. The safer the better.

[reveman, 2015/08/14 12:36:32]

Ok, I buy that.

How about we add "operator int() const { return id; }" so we don't have to type
id.id all over the place?

+ public:
+  int id;
+
+  // Invalid ID is -1 to match semantics of base::StaticAtomicSequenceNumber.
+  GenericSharedMemoryTracingId() : id(-1) {}
+  explicit GenericSharedMemoryTracingId(int id) : id(id) {}
+  GenericSharedMemoryTracingId(const GenericSharedMemoryTracingId& other) =
+      default;
+  GenericSharedMemoryTracingId& operator=(
+      const GenericSharedMemoryTracingId& other) = default;
+
+  bool operator==(const GenericSharedMemoryTracingId& other) const {
+    return id == other.id;
+  }
+};
+
+// Generates GUID which can be used to trace shared memory using its
+// GenericSharedMemoryId.
+BASE_EXPORT base::trace_event::MemoryAllocatorDumpGuid
+GetGenericSharedMemoryGUIDForTracing(
+    uint64_t tracing_process_id,
+    GenericSharedMemoryTracingId generic_shared_memory_tracing_id);
+
+}  // namespace gfx
+
+namespace BASE_HASH_NAMESPACE {
+template <>
+struct hash<gfx::GenericSharedMemoryTracingId> {
+  size_t operator()(gfx::GenericSharedMemoryTracingId key) const {
+    return BASE_HASH_NAMESPACE::hash<int>()(key.id);
+  }
+};
+}  // namespace BASE_HASH_NAMESPACE
+
+#endif  // UI_GFX_GENERIC_SHARED_MEMORY_TRACING_ID_H_