Bug 176449 - [DFG][FTL] ArrayBuffer creation should be handled
Summary: [DFG][FTL] ArrayBuffer creation should be handled
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Yusuke Suzuki
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-06 05:03 PDT by Yusuke Suzuki
Modified: 2017-09-07 09:17 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yusuke Suzuki 2017-09-06 05:03:01 PDT
While we have NewTypedArray, we do not have a node for `new ArrayBuffer`.
We should have it since Octane/zlib repeatedly calls it.
Comment 1 Yusuke Suzuki 2017-09-06 06:37:23 PDT
My plan is

1. Making JSArrayBuffer thing like JSArrayBufferView
2. TypedArray has a mode pointing JSArrayBuffer.
Comment 2 Yusuke Suzuki 2017-09-07 07:36:01 PDT
I'll add JSArrayBufferBase, which is the current JSArrayBufferView.
And JSArrayBufferView will inherit this JSArrayBufferBase.

And JSArrayBuffer will use JSArrayBufferBase for its implementation. And it may have fast allocation.

And We also add a new mode to JSArrayBufferBase, which holds JSArrayBuffer's reference.
Comment 3 Yusuke Suzuki 2017-09-07 08:34:35 PDT
(In reply to Yusuke Suzuki from comment #2)
> I'll add JSArrayBufferBase, which is the current JSArrayBufferView.
> And JSArrayBufferView will inherit this JSArrayBufferBase.
> 
> And JSArrayBuffer will use JSArrayBufferBase for its implementation. And it
> may have fast allocation.
> 
> And We also add a new mode to JSArrayBufferBase, which holds JSArrayBuffer's
> reference.

Hmm, once ArrayBuffer is shared between multiple views, we need to materialize it...
Comment 4 Filip Pizlo 2017-09-07 08:52:30 PDT
(In reply to Yusuke Suzuki from comment #1)
> My plan is
> 
> 1. Making JSArrayBuffer thing like JSArrayBufferView
> 2. TypedArray has a mode pointing JSArrayBuffer.

How do you plan to support neutering?

How do you plan to support some of the other weird stuff the DOM can do?
Comment 5 Filip Pizlo 2017-09-07 09:10:15 PDT
It might be useful to identify exactly what about the current array buffer creation is slow. Is it malloc?  Is it then GC?  Just that it’s not inlined?
Comment 6 Yusuke Suzuki 2017-09-07 09:12:38 PDT
Following is rough sketch. I'm still considering the possible design.

(In reply to Filip Pizlo from comment #4)
> (In reply to Yusuke Suzuki from comment #1)
> > My plan is
> > 
> > 1. Making JSArrayBuffer thing like JSArrayBufferView
> > 2. TypedArray has a mode pointing JSArrayBuffer.
> 
> How do you plan to support neutering?

JSArrayBuffer knows about neutering state. (pointer may become nullptr). And typed arrays using this buffer also know this state since they holds the reference to this JSArrayBuffer*.

> 
> How do you plan to support some of the other weird stuff the DOM can do?

Now I'm exploring the possible designs right now :D
One thing I come up with is that ArrayBuffer holds strong ref to AuxiliarySpace for fast ArrayBuffer allocation. Since ArrayBuffer's auxiliary space just holds byte sequence, no cyclic reference occurs. And now auxiliary space is not moved, holding the pointer to this space in the other typed arrays is safe.

var buffer = new ArrayBuffer(...);
var a = new Uint8Array(buffer);
var b = new Uint8Array(buffer);
// a and b just points to JSArrayBuffer's buffer with usual WriteBarrier<>. a and b has void* vector to buffer's underlying data. But this pointer will not be changed.
// a and b can know whether the underlying buffer is neutered since a and b have reference to buffer. And buffer knows it.

// Some DOM ops. We get Ref<ArrayBuffer> from buffer. At that time, Ref<ArrayBuffer> can hold strong ref to auxiliary buffer allocated for JS buffer.
Comment 7 Yusuke Suzuki 2017-09-07 09:17:12 PDT
(In reply to Filip Pizlo from comment #5)
> It might be useful to identify exactly what about the current array buffer
> creation is slow. Is it malloc?  Is it then GC?  Just that it’s not inlined?

Yeah, good point. I'm seeing that ArrayBuffer construction is frequently shown in sampling profiler result for zlib. I need to look into it more carefully to see what is costly.
Possibly I think redesign of ArrayBuffer can reduce the several cost.

1. Inlining ArrayBuffer allocation

If we can just use NewTypedArray like thing, we can allocate it inlinely.

2. Do fast allocation for ArrayBuffer

We can allocate ArrayBuffer in a fast way by using auxiliary allocation if the buffer size is small. Currently, zlib uses `new ArrayBuffer`. It always allocates JSArrayBuffer with C++ ArrayBuffer.

3. Introducing NewTypedArray(ArrayBufferUse) with complete inlining allocation

If typed array can just hold the ref to JSArrayBuffer (and setup vector pointer etc.), we can inline this pattern too. (and the actual operation also becomes very cheap).