V8 4.4 to remove indexed properties via external data

[jeisinger]

Hey,

I'm about to remove SetIndexedPropertiesToExternalArrayData and related APIs from V8. I think there are some callsites of this API in io.js that would need to be updated.

You should use the standardized ArrayBuffers / ArrayBufferViews instead.

CL to remove them is here: https://codereview.chromium.org/1092923002

this will land in V8 4.4

[bnoordhuis]

I just saw the email on v8-dev and I've left a comment. I appreciate the heads up and I can't stress enough the impact that change will have on the io.js and node.js ecosystem.

[mscdex]

Yikes

[jeisinger]

I realize this is disruptive, but I don't see how it's fundamentally different from e.g. the MaybeLocal<> or Persistent<> changes that also force existing embedders to update.

anyway, as I mentioned on the CL, we'll discuss this internally. Will update this issue with the outcome.

[mscdex]

@bnoordhuis Doesn't this mean that it would no longer be possible to have Buffer?

[jeisinger]

the same functionality is provided by the ArrayBuffer API. The javascript objects will look exactly the same.

[petkaantonov]

It's not just compatibility but you can't implement something like SharedArrayBuffer (partial ownership transfers) with only ArrayBuffer api

[Fishrock123]

iirc ArrayBuffer APIs aren't able to completely replace Buffer?

See @petkaantonov's comment..

We'd need enough hooks to at least make a replacement...

[jeisinger]

All those use cases should be supported. If you have a concrete instance of
problem, I'm happy to help

On Fri, Apr 17, 2015, 5:38 PM Jeremiah Senkpiel notifications@github.com
wrote:

iirc ArrayBuffer APIs aren't able to completely replace Buffer? We'd need
enough (something) to at least make a replacement...

—
Reply to this email directly or view it on GitHub
#1451 (comment).

[meandmycode]

I feel if there aren't any blocking functionality issues then this is ok.

It seems more of an agenda issue to say making breaking changes is unacceptable. It won't break node as node lives on v8 from the past and they've said they won't update v8 often because of changes like this.

Whereas iojs was willing to take the hit for the better engine, I'm not sure you can always have your cake and eat it..

If iojs has an agenda to keep up with v8 then it also needs to point out that this can be disruptive to native modules.

[bmeck]

I think you can do transferable ArrayBuffers using ArrayBuffer::Externalize(), ArrayBuffer::Neuter(), then ArrayBuffer::New(). Or if you want shared mutation don't Neuter() after Externalize(). @jeisinger does that sound right?

[jeisinger]

You can just allocate the memory yourself using the ArrayBufferAllocator node already defines and pass that memory to ArrayBuffer::New()

I'd put the pointer to the underlying memory in one of the internal fields of the arraybuffer (via SetAlignedPointerInInternalField) because the ArrayBuffer::Externalize API only gives you the pointer once...

If there are additional APIs you'd need on ArrayBuffer, ArrayBufferView, or the typed Arrays, we can certainly add them there.

[jeisinger]

basically, what will be dropped is the ability to add external data to any object. Instead, the object needs to inherit from one of the typed array types (ArrayBufferView) or DataView.

All other functionality will stay - if something is not accessible via the typed array API this can be easily fixed.