Add an API to let the embedder associate arbitrary data with a v8::Context.

Add an API to let the embedder associate arbitrary data with a v8::Context.

I had hoped that v8::Context::SetData would let the embedder associate a void*
with a v8::Context, but it turns out we can't use that API because the debugger
makes assumptions about the sorts of values that will be stored via that API.

See https://bugs.webkit.org/show_bug.cgi?id=98679 for more context.

[Sven Panne, 2012-10-09 06:30:47]

I took a look into the WebKit issue, and I think that your problems are related
to the currently broken External class: Although it is declared as a subclass of
Value (i.e. promises to return a JavaScript object), Wrap/New can currently
return an internal object (a Foreign), which in turn causes the assertion you
mention in the isssue to be triggered.

I think the current CL is probably not needed when we agree on the proposal I
suggested last week: Add an API for accessing aligned pointers, making External
a real Value, and deprecating the old unaligned pointer API plus Wrap/Unwrap.

[abarth-chromium, 2012-10-09 07:05:47]

On 2012/10/09 06:30:47, Sven Panne wrote:
> I took a look into the WebKit issue, and I think that your problems are
related
> to the currently broken External class: Although it is declared as a subclass
of
> Value (i.e. promises to return a JavaScript object), Wrap/New can currently
> return an internal object (a Foreign), which in turn causes the assertion you
> mention in the isssue to be triggered.

Yes, that's what causes the ASSERT.

> I think the current CL is probably not needed when we agree on the proposal I
> suggested last week: Add an API for accessing aligned pointers, making
External
> a real Value, and deprecating the old unaligned pointer API plus Wrap/Unwrap.

That's certainly possible.

What's going on here is that we have a class (V8PerContextData) that holds a
bunch of WebKit data associated with a v8::Context.  We need to be able to get
to that object quickly from a handle to a v8::Context.  I don't particularly
care what mechanism we use---just as long as it is fast.  :)

I ran into trouble with v8::Context::SetData because of the External/Foreign
issue.  I also had trouble removing all of the WebKit-side code that's using
SetData because there's a bunch of code that integrates with the V8 debugger
that reads the data from JavaScript (rather than from C++).  Even if we solve
the External/Foreign issue, I'm not sure if I actually use SetData because of
that issue.

[abarth-chromium, 2012-10-09 07:26:55]

Add an API to let the embedder associate arbitrary data with a v8::Context.

I had hoped that v8::Context::SetData would let the embedder associate a void*
with a v8::Context, but it turns out we can't use that API because the debugger
makes assumptions about the sorts of values that will be stored via that API.

See https://bugs.webkit.org/show_bug.cgi?id=98679 for more context.

[abarth-chromium, 2012-10-09 07:29:28]

I've updated the patch to re-phrase the API in terms of void* rather than
Handle<Value>.  That way, we can change the implementation later when we want to
get rid of External.

@Sven: Do you think we should move forward with this patch while we work out
what to do with External and pointer alignment?

[Sven Panne, 2012-10-09 08:35:11]

Extending the Context API with yet another field (of different type) is not very
nice, because it hacks in just one specialized use case. I think that the right
way would be providing a more general API in Context for adding any number of
embedder data fields, similar to the proposed API for Object:

class Context {
  ...
  Local<Value> GetInternalField(int index);
  void SetInternalField(int index, Handle<Value> data);

  void* GetAlignedPointerFromInternalField(int index);
  void SetAlignedPointerInInternalField(int index, void* ptr);
}

The number of internal fields would be dynamic (i.e. we would reallocate if
necessary), and the old SetData/GetData will be deprecated, but implemented via
field 0 in the meantime. We can probably totally inline the getters in the
header, so things would be quite efficient.

This would be consistent with the other proposal, we will be able solve the
typing problems with External, and you can even associate any number of embedder
data with a Context.

If this is OK, I think I can implement all this in the new one or two days...

[abarth-chromium, 2012-10-09 15:42:02]

> If this is OK, I think I can implement all this in the new one or two days...

Sure, that sounds great.  Thanks for giving this issue some attention!