Bug 190800 – [JSC] Implement BigInt64Array and BigUint64Array

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Caio Lima]

...

[Yusuke Suzuki]

Because we need to view contiguous int64_t* / uint64_t* memory region via this view, the storage should be just byte sequence. And [] access should wrap the result with JSBigInt when it is accessed from JS world.

This would be nice to have for that: https://github.com/takahirox/riscv-rust/issues/115

[Hao Li]

We also have the requirement for BigUint64Array in WebGPU: https://github.com/gpuweb/gpuweb/issues/866

Generally it would be helpful for all projects using wasm_bindgen (https://github.com/rustwasm/wasm-bindgen), so also for the jsapi of the rav1e (https://github.com/xiph/rav1e/tree/master/rav1e_js).

[Slim Lim]

Echoing the previous comment, lack of BigUint64Array support means that applications using wasm-bindgen cannot run at all in Safari. This is especially problematic for targeting the iPad.

[Yusuke Suzuki]

Created attachment 418810 [details]
Patch

[Yusuke Suzuki]

Created attachment 418811 [details]
Patch

[Yusuke Suzuki]

Created attachment 418812 [details]
Patch

[Yusuke Suzuki]

Created attachment 418813 [details]
Patch

[Yusuke Suzuki]

Created attachment 418814 [details]
Patch

[Yusuke Suzuki]

Created attachment 418821 [details]
Patch

[Ross Kirsling]

Comment on attachment 418821 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=418821&action=review

r=me, this is awesome!

> Source/JavaScriptCore/runtime/AtomicsObject.h:65
> +JSArrayBufferView* validateTypedArray(JSGlobalObject*, JSValue);

This seems kind of weird? AtomicsObject.cpp needs to include JSArrayBufferView.h anyway, doesn't it?

> Source/JavaScriptCore/runtime/JSGenericTypedArrayView.h:98
> +    using Adaptor = PassedAdaptor;

What's the purpose of this alias?

> Source/JavaScriptCore/runtime/JSGenericTypedArrayViewInlines.h:462
> +    if constexpr (Adaptor::canConvertToJSQuickly)

Cool!

> JSTests/test262/expectations.yaml:831
> +test/built-ins/TypedArray/prototype/filter/BigInt/callbackfn-detachbuffer.js:
> +  default: 'TypeError: Invalid argument type in ToBigInt operation (Testing with BigInt64Array.)'
> +  strict mode: 'TypeError: Invalid argument type in ToBigInt operation (Testing with BigInt64Array.)'
> +test/built-ins/TypedArray/prototype/findIndex/BigInt/predicate-may-detach-buffer.js:
> +  default: 'Test262Error: throws a TypeError getting a value from the detached buffer Expected a TypeError to be thrown but no exception was thrown at all (Testing with BigInt64Array.)'
> +  strict mode: 'Test262Error: throws a TypeError getting a value from the detached buffer Expected a TypeError to be thrown but no exception was thrown at all (Testing with BigInt64Array.)'

Do you want to submit the patch for these or would you prefer that I do it?

[Yusuke Suzuki]

Comment on attachment 418821 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=418821&action=review

>> Source/JavaScriptCore/runtime/AtomicsObject.h:65
>> +JSArrayBufferView* validateTypedArray(JSGlobalObject*, JSValue);
> 
> This seems kind of weird? AtomicsObject.cpp needs to include JSArrayBufferView.h anyway, doesn't it?

Right! I'll remove it.

>> Source/JavaScriptCore/runtime/JSGenericTypedArrayView.h:98
>> +    using Adaptor = PassedAdaptor;
> 
> What's the purpose of this alias?

Because we would like to access ViewClass::Adaptor.

>> JSTests/test262/expectations.yaml:831
>> +  strict mode: 'Test262Error: throws a TypeError getting a value from the detached buffer Expected a TypeError to be thrown but no exception was thrown at all (Testing with BigInt64Array.)'
> 
> Do you want to submit the patch for these or would you prefer that I do it?

I'll quickly do that after landing this patch :)

[Yusuke Suzuki]

Committed r272170: <https://trac.webkit.org/changeset/272170>

[Radar WebKit Bug Importer]

<rdar://problem/73842238>