Add CefV8BackingStore for off-thread ArrayBuffer data population

[pkiers]

Summary

• Adds CefV8BackingStore class that wraps V8's ArrayBuffer::BackingStore, allowing the backing memory to be allocated on the renderer thread and populated (e.g. memcpy) on a background thread
• Adds CefV8Value::CreateArrayBufferFromBackingStore() static method to create an ArrayBuffer from a pre-populated backing store in a zero-copy operation
• Works with V8 sandbox enabled, unlike CreateArrayBuffer (external buffer)

Motivation

Currently with V8 sandbox enabled, CreateArrayBuffer is not supported and CreateArrayBufferWithCopy performs the memcpy on the JS thread. For large buffers this blocks the renderer. This API enables:

1. Renderer thread: CefV8BackingStore::Create(size) — allocate sandbox-compatible memory
2. Background thread: write data into Data() pointer — expensive work off JS thread
3. Renderer thread: CreateArrayBufferFromBackingStore(store) — zero-copy ArrayBuffer creation

API

class CefV8BackingStore : public virtual CefBaseRefCounted {
  static CefRefPtr<CefV8BackingStore> Create(size_t byte_length);
  virtual void* Data() = 0;
  virtual size_t ByteLength() = 0;
  virtual bool IsValid() = 0;
};

// On CefV8Value:
static CefRefPtr<CefV8Value> CreateArrayBufferFromBackingStore(
    CefRefPtr<CefV8BackingStore> backing_store);

Test plan

• cef_unittests --gtest_filter="V8Test.ArrayBufferBackingStore" — covers creation, data access, zero-copy ArrayBuffer, consumption invalidation, double-use rejection, and neutering
• Translator tool generates wrappers without errors
• Verify with V8 sandbox both enabled and disabled

[magreenblatt]

Thanks for this PR. Please see comments inline.

[pkiers]

Thanks for the review, comments have been resolved.

I was wondering if I would make getter for CefV8ArrayBuffer to retreive the underlying CefV8BackingStore also. It already has Data getter. What you think?

[magreenblatt]

New classes/methods need to be protected by #if CEF_API_ADDED(CEF_NEXT) with appropriate /*--cef(added=next)--*/ metadata. See https://bitbucket.org/chromiumembedded/cef/wiki/ApiVersioning.md#markdown-header-usage-in-pull-requests

[pkiers]

Thanks, fixed that

[magreenblatt]

Do we need a warning here about not keeping a pointer reference after passing to CreateArrayBufferFromBackingStore?

[pkiers]

Added a warning to the Data() doc comment: "Pointers obtained from this method should not be retained after calling CreateArrayBufferFromBackingStore(), as the memory will then be owned by the ArrayBuffer and subject to V8 garbage collection."

[nik-sp]

Hey, thanks for the PR!

I have a question about the base::Lock lock_ in CefV8BackingStoreImpl. Could you explain the reasoning behind it?

As I see it, the lock doesn't fully make the class thread-safe. It protects individual method calls, but once Data() returns, the lock is released and the caller holds a raw pointer with no protection. Another thread can then call TakeBackingStore(), leaving the first thread with a dangling pointer.

What do you think about removing the lock and instead documenting that the class is safe to pass between threads, but not to share across threads simultaneously? This seems to match the intended usage pattern:

Renderer thread: Create backing store
       ↓ (pass)
Background thread: Populate via Data()
       ↓ (pass)
Renderer thread: CreateArrayBufferFromBackingStore()