Support for all primitive array types (i16, u8, f32, etc.)

[Permille]

I have a feeling that limiting this proposal to only work on i8 arrays (i.e. (array i8) and (array (mut i8))) would not really bring any benefits with regard to ease of implementation, and would only preclude other potential use-cases. Given that the current version of this proposal already assumes that i8 arrays are likely to be backed by some packed memory buffer through which performant multi-byte accesses are possible, I don't think it's a stretch to further assume that all array types with any primitive or packed numeric type will be backed by untyped memory buffers which can also support multibyte array accesses.

For example, the JS String Builtins proposal works with the (array (mut i16)) type to represent UTF-16 characters in strings. By limiting this proposal to just i8 arrays, it would still not be possible to speed up certain string operations with SIMD, which could otherwise enable faster parsing, string lookups, regular expressions, etc. Remember that in the current GC proposal, there is no way to cast between different array types.

@brendandahl let me know what you think about this.

[brendandahl]

The i8 limitation is mainly their to keep the proposal small and I also don't think we had any real world use cases for larger types. The JS string builtins using i16 is definitely an interesting use case though.

I remember some of the v8 engine devs mentioning they would not like to support casting between array types, but I can't remember if they had any issues with multibyte access to different array types.

Maybe @Liedtke has some thoughts on allowing multibyte reads/writes on other array types?

[Liedtke]

Maybe @Liedtke has some thoughts on allowing multibyte reads/writes on other array types?

I am not very familiar with the different options in this proposal. I think I spoke up somewhere that we can't do some kind of reinterpret_cast on wasm-gc objects.
So an array of an i8 can't become an i16 array (or look like one). The data of an array is "inline", similar to variable-length arrays in a C struct.

With the current proposal, we just add a new operation on array i8 that isn't different from an array.set, it just writes multiple values. Allowing the multi-byte access on other array-types itself probably wouldn't be much of an issue for us, it's really just another "overload" of the instruction.¹
The bounds-check would be have to multiply the size of the array by its element size to get to the size in bytes but conceptually it's the same?²

Views would be different. If there was a view on an array, then running an i32.store on the view will actually modify the referenced array (even though it is not used by the operation), so when it comes to e.g. load elimination this might be a bit more difficult to handle for the aliasing rules (currently V8 doesn't do any load elimination for array element accesses though).

For shared Wasm-gc arrays we already use 8-Byte-alignment for all of their data to allow atomic i64 accesses³ and we don't differentiate between the different element types, so we already pay the potential alignment gap for all of the different element types. (Unshared Wasm-gc arrays are 4-Byte-aligned in Chrome).

Footnotes

1. Does this violate the "no overloading" principle that Wasm has apparently? (https://github.com/WebAssembly/shared-everything-threads/pull/110#issuecomment-4216333083) ↩

2. I'd heavily question the use case for using f32, f64 (or the proposed f16) as an allowed element type. If we allow the multi-byte accesses on arrays with integral types, why would you want to use an f32 array as the underlying type and not simply an i8 array (or i16 array if you want to inter-operate with the JS string builtins)? ↩

3. As some platforms have this requirement; we enforce the alignment on all platforms though. ↩

[Permille]

Hi @brendandahl and @Liedtke, thanks for your comments.

In another github issue, I proposed introducing views and being able to do multi-byte accesses on them in favour of arrays. Thanks to @brendandahl's comment on the issue I can see that my idea is indeed very similar to the slice proposal.

Given that the proposed slice construct would also support multi-byte loads and stores, I am now unsure I understand what exactly the purpose of this current proposal would be. It seems to me that the slices would cover essentially the same functionality, though it appears that the slice proposal does not mention "special" memory accesses like those from v128 SIMD or threading intrinsics.

Generally, I think it would be really bad to have multiple disjoint ways of accessing memory from varying sources (no less with differing capabilities), and I fear that this would happen if both of these proposals were to go ahead. This is one of the reasons why I proposed supporting all primitive array types: if there were no underlying technical reasons for why they could not be supported, creating artificial limitations (or complexities) would, in my opinion, just create further issues downstream in areas like compiler code emission.

I think I spoke up somewhere that we can't do some kind of reinterpret_cast on wasm-gc objects. So an array of an i8 can't become an i16 array (or look like one). The data of an array is "inline", similar to variable-length arrays in a C struct.

Could you please elaborate on why this is the case? I find this really surprising, because the Javascript equivalent of this is possible (i.e. "reinterpret-casting" array buffers by creating different typed arrays backed by the same buffer). Also, if multi-byte array accesses are theoretically possible on all numeric gc array types, then surely reinterpret casting them would be fine too? I understand that reinterpret-casting is not universally possible given that GC arrays can also store opaque reference types, but I can't think of any issues here except for bounds checking when reinterpret-casting to a wider element type.

shared Wasm-gc arrays

This isn't related to the above, but I didn't know Chrome supports shared GC arrays -- I thought there was no way to share wasm gc objects between threads. Is this in preparation of supporting the shared everything threads proposal or something else?

[tlively]

Given that the proposed slice construct would also support multi-byte loads and stores, I am now unsure I understand what exactly the purpose of this current proposal would be.

The advantage of slices is that they abstract away the underlying storage. The same code could use a slice backed by any kind of array. But they pay for this flexibility with extra indirection, including a separate slice object. The advantage of multibyte array access is that there is no extra indirection, but you can't abstract over the underlying storage.

In principle there's room for both proposals because they fill different niches, but in practice it might only make sense for one to move forward.

I think I spoke up somewhere that we can't do some kind of reinterpret_cast on wasm-gc objects...

Could you please elaborate on why this is the case? I find this really surprising, because the Javascript equivalent of this is possible

WebAssembly arrays need to be able to be cast with ref.test, ref.cast, etc, so they contain runtime type information in addition to the arrays contents. That type information is part of the array itself, not the array reference, so it's not possible to have multiple references to the same array with different types.

This works in JS because there are extra layers of indirection between the JS object the programmer interacts with and the actual underlying data.

shared Wasm-gc arrays

This isn't related to the above, but I didn't know Chrome supports shared GC arrays -- I thought there was no way to share wasm gc objects between threads. Is this in preparation of supporting the shared everything threads proposal or something else?

This is part of an experimental prototype for (part of) shared-everything threads, yes. It's not enabled by default.

[Permille]

Thank you, I understand now. Sorry, I had just skimmed the slice proposal, and it makes sense that it would require an extra indirection over all memory accesses. I had originally hoped that using views/slices over entire arrays could somehow be done without indirection. So I think that having this proposal would be valuable after all :)

Something I really like about this proposal is that it "reuses" existing memory access instructions by just adding an extra immediate flag to distinguish them from linear memory accesses. The main advantages I can see from this are that it keeps the instruction set smaller, and would also make it easier for proposals in the future to add new memory access instructions. Do you think there is any scope for doing that in the slice proposal also?

And lastly, do you know if there is a roadmap for the slice proposal? I can see that the last comments were from a year ago and I couldn't find a matching proposal repository. I would be happy to take it up if there is nobody currently working on it.