Add Blob API

Add Blob API

Discussion:
http://groups.google.com/group/v8-dev/browse_thread/thread/dba28a81d9215291

Bug: http://code.google.com/p/v8/issues/detail?id=270

[ry, 2009-11-14 19:43:00]

Hi Christian,

Is this on the right track? What do you think about the GetAddress() method? I
think it would be very useful!

I'm not sure if this is working on x64 (although the test passes); are
ByteArrays still backed by uint8_t arrays?

ry

[Christian Plesner Hansen, 2009-11-16 12:12:22]

I agree that SetIndexedPropertiesToExternalArrayData which was introduced only a
few weeks ago is probably closer to what you want.

I've looked through the code anyway.  Except for giving out a derived pointer
(see below) it looks okay to me.

http://codereview.chromium.org/391068/diff/1/3
File src/api.cc (right):

http://codereview.chromium.org/391068/diff/1/3#newcode1657
Line 1657: "Could not convert to external");
I expect you mean "...to blob".

http://codereview.chromium.org/391068/diff/1/3#newcode2982
Line 2982: i::Handle<i::Object> obj = Utils::OpenHandle(this);
Doesn't OpenHandle give you back a ByteArray that you can just use without
casting?

http://codereview.chromium.org/391068/diff/1/3#newcode3004
Line 3004: return i::ByteArray::cast(*obj)->GetDataStartAddress();
Danger danger!  This will give you a derived pointer which may be invalidated by
the GC at any time.  The only thing you can do safely is block read/write like
we do on strings.

http://codereview.chromium.org/391068/diff/1/5
File test/cctest/test-api.cc (right):

http://codereview.chromium.org/391068/diff/1/5#newcode1414
Line 1414: env->Global()->Set(v8_str("blob"), blob);
Like externals it is not safe to expose blobs directly to JavaScript code.  You
have to wrap it as an internal field of a v8::Object.

[ry, 2009-11-16 12:32:00]

On 2009/11/16 12:12:22, Christian Plesner Hansen wrote:
> Except for giving out a derived pointer
> (see below) it looks okay to me.

So, I'm trying to avoid a memcpy. I'd like to be able to recv() directly into
the V8 heap. As long as no V8 functions are called, the GC shouldn't run. Could
a method like this be exposed if it was surrounded by a big scary warning and
combined with safer WriteBytes() and ReadBytes() methods?

SetIndexedPropertiesToExternalArrayData() is not ideal because I'd like to pass
the data through V8, then have a C++ handler unwrap the data and access it
again. (My use case is a TCP socket which receives data, passes it through V8,
to a C-language HTTP parser.)

Ideally I could use recv() into V8 Blob, pass it via Javascript to the parser,
which could unwrap and parse the data without ever copying the data.

Thanks! ry

[ry, 2009-11-16 12:54:38]

Thinking about this some more, I suppose just using an External is probably
best. I like the idea of having the memory managed by V8 without doing the weak
reference callback, but maybe that's not a big enough reason to justify exposing
an unsafe pointer.

ry

[Christian Plesner Hansen, 2009-11-16 13:05:03]

> So, I'm trying to avoid a memcpy. I'd like to be able to recv() directly into
> the V8 heap. As long as no V8 functions are called, the GC shouldn't run.
Could
> a method like this be exposed if it was surrounded by a big scary warning and
> combined with safer WriteBytes() and ReadBytes() methods?

So far we've resisted the temptation to allow unsafe operations.  We could also
have used something like this for strings in the chromium binding layer but
decided against it then, and I don't see that changing.

> SetIndexedPropertiesToExternalArrayData() is not ideal because I'd like to
pass
> the data through V8, then have a C++ handler unwrap the data and access it
> again. (My use case is a TCP socket which receives data, passes it through V8,
> to a C-language HTTP parser.)

Unless the backing array has a life completely separate of the JS object it's
used in I don't know what prevents that.  You can make the backing array
available from the JS object and grab it when you need it in C++.

> Ideally I could use recv() into V8 Blob, pass it via Javascript to the parser,
> which could unwrap and parse the data without ever copying the data.

Our experience has been that memcpy usually isn't a bottleneck but that depends
on your application.