[BlobAsync] Patch 4: Browser Classes & Logic.

storage/browser/blob/blob_async_transport_strategy.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 STORAGE_BROWSER_BLOB_BLOB_ASYNC_TRANSPORT_STRATEGY_H_
+#define STORAGE_BROWSER_BLOB_BLOB_ASYNC_TRANSPORT_STRATEGY_H_
+
+#include <map>
+#include <vector>
+
+#include "base/macros.h"
+#include "base/memory/scoped_ptr.h"
+#include "storage/browser/blob/blob_data_builder.h"
+#include "storage/browser/storage_browser_export.h"
+#include "storage/common/blob_storage/blob_item_bytes_request.h"
+#include "storage/common/data_element.h"
+
+namespace storage {
+
+// This class computes and stores the strategy for asynchronously transporting
+// memory from the renderer to the browser.
+//
+// tl;dr:
+// We take memory constraints of our system and the description of a blob, and
+// generate data requests for that blob's memory and a seed a BlobDataBuilder
+// for storing that data.
+//
+// This class does not compute requests by using the 'shortcut' method, where
+// the data is already present in the blob description, and will always give
+// the caller the full strategy for requesting all data from the renderer. The
+// returned builder will always have TYPE_BYTES_DESCRIPTION items for the future
+// memory locations.
+// This involves two transformations:
+// 1. Transforming the data storage to be efficient in-transport.  This can
+//    mean that data is consolidated from cross-blob or cross-file boundaries
+//    in the blob in a common block of shared memory or a file.
+// 2. Transforming the transport data into the browser storage representation.
+//    This can simply mirror the renderer representation, or it can be instead
+//    pointing to transport representation with offsets and sizes.
+//
+// The following information is generated:
+// 1. The total bytes size of memory items.
+// 2. The requests for memory, segmented as described above, along with their
+//    destination browser indexes and offsets
+// 3. The sizes of the shared memory and file handles being used (by handle
+//    index) in the async operation.
+// 4. A BlobDataBuilder which can be used to construct the Blob in the
+//    BlobStorageContext object, after the TYPE_BYTES_DESCRIPTION entries are
+//    turned into TYPE_BYTES entries.
+// The initial implementation of this is simple, but the protocol allows any
+// sort of flexibility, as everything has an offset and size specified.
+class STORAGE_EXPORT BlobAsyncTransportStrategy {
+ public:
+  enum Error {
+    ERROR_NONE = 0,
+    ERROR_TOO_LARGE,  // This item can't fit in disk or memory
+    ERROR_INVALID_PARAMS
+  };
+
+  struct RendererMemoryItemRequest {
+    RendererMemoryItemRequest();
+    // This is the index of the item in the builder on the browser side.
+    size_t browser_item_index;
+    // Note: For files this offset should always be 0, as the file offset in
+    //       segmentation is handled by the handle_offset in the message.  This
+    //       offset is used for populating a chunk when the data comes back to
+    //       the browser.
+    size_t browser_item_offset;
+    BlobItemBytesRequest message;
+    bool received;
+  };
+
+  BlobAsyncTransportStrategy();
+  virtual ~BlobAsyncTransportStrategy();
+
+  // This call does the computation to create the requests and builder for the
+  // blob given the memory constraints and blob description.
+  // 'memory_available' is the total amount of memory we can offer for storing
+  // blobs.
+  void Initialize(size_t max_ipc_memory_size,
+                  size_t max_shared_memory_size,
+                  uint64_t max_file_size,
+                  uint64_t disk_space_left,
+                  size_t memory_available,
+                  const std::string& uuid,
+                  const std::vector<DataElement>& blob_item_infos);
+
+  // In the current algorithm, the file sizes will always be sorted from largest
+  // to smallest.
+  std::vector<uint64_t>& file_handle_sizes() { return file_handle_sizes_; }
+
+  // In the current algorithm, the shared memory sizes will always be sorted
+  // from largest to smallest.
+  std::vector<size_t>& shared_memory_handle_sizes() {
+    return shared_memory_handle_sizes_;
+  }
+
+  const std::vector<RendererMemoryItemRequest>& requests() const {
+    return requests_;
+  }
+
+  BlobDataBuilder* blob_builder() { return builder_.get(); }
+
+  uint64_t total_bytes_size() const { return total_bytes_size_; }
+
+  Error error() const { return error_; }
+
+  static bool ShouldBeShortcut(const std::vector<DataElement>& items,
+                               size_t memory_available);
+
+ protected:
+  friend class FileStorageStrategy;
+  friend class SharedMemoryStorageStrategy;
+
+  template <typename SizeType>
+  class BlobSegmentVisitor {
+   public:
+    virtual ~BlobSegmentVisitor(){};
+    virtual void VisitBytesSegment(size_t element_index,
+                                   SizeType element_offset,
+                                   size_t segment_index,
+                                   SizeType segment_offset,
+                                   SizeType size) = 0;
+    virtual void VisitNonBytesSegment(const DataElement& element,
+                                      size_t element_index) = 0;
+    virtual void Done() = 0;
+  };
+
+  // This iterates of the data elements and segments the 'bytes' data into
+  // the smallest number of segments given the max_segment_size.
+  // The callback describes either:
+  // * A non-memory item
+  // * A partition of a bytes element which will be populated into a given
+  //   segment and segment offset.
+  // Assumptions: All memory items are consolidated.  As in, there are no two
+  //              'bytes' items next to eachother.
+  template <typename SizeType>
+  static void ForEachWithSegment(const std::vector<DataElement>& items,
+                                 SizeType max_segment_size,
+                                 BlobSegmentVisitor<SizeType>* visitor);
+
+ private:
+  // This simply fills the segment_sizes vector with the sizes of segments that
+  // would be used to partition a block of total_memory_size.

[michaeln, 2015/11/21 00:59:46]

It's easier and clearer to read the code than the comment. Method might be
simple enough to not need a comment at all.

[dmurph, 2015/11/23 20:07:02]

Done.

+  template <typename SizeType>
+  static void ComputeHandleSizes(SizeType total_memory_size,
+                                 SizeType max_segment_size,
+                                 std::vector<SizeType>* segment_sizes);
+
+  Error error_;
+
+  std::vector<uint64_t> file_handle_sizes_;
+  // can be size_t, but same as file handles so we can use the same methods.

[michaeln, 2015/11/21 00:59:45]

This comment doesn't seem useful. I think its referring to a slightly different
design that was not taken.

[dmurph, 2015/11/23 20:07:02]

whoops, yeah you're right.

+  std::vector<size_t> shared_memory_handle_sizes_;
+
+  uint64_t total_bytes_size_;
+  std::vector<RendererMemoryItemRequest> requests_;
+  scoped_ptr<BlobDataBuilder> builder_;
+
+  DISALLOW_COPY_AND_ASSIGN(BlobAsyncTransportStrategy);
+};
+
+}  // namespace storage
+
+#endif  // STORAGE_BROWSER_BLOB_BLOB_ASYNC_TRANSPORT_STRATEGY_H_