Repository navigation
Supporting subarray: false for owned views #19
Description
I'm exploring Wasm memory models for the next generation of wasm-bindgen ABIs and came across this excellent proposal, which I also as other delegates consider to very much still have value after immutable array buffers.
The use case I'm interested in here is how WebAssembly allocators might be able to share allocated buffer ownership with JS and host APIs in a way that the WebAssembly allocator can free that range of memory in the embedded allocator when the view is finalized.
The model I'm thinking of here is creating a view that "owns" the underlying allocator byte view inside of the Wasm ArrayBuffer from the perspective of the allocator with a finalizer that then frees the buffer on the finalization of the TypedArray view itself.
This model only works if we have a reliable finalizer though - thus the need to ban all derived subarrays by reference.
If we could ban subarrays and know that no other views can be constructed from this view, then we could guarantee a sort of ownership model of a buffer to Wasm memory in JS, where the GC is able to reclaim that Wasm allocation.
It should be a fairly simple orthogonal addition to the proposal - that this proposal hides .buffer is already half the job. The remaining part is really just to ban subarray() from working which is actually the comprehensive path. Although if derived view constructors are added in the new proposal we'd also want to include this.
Happy to help out and explore options here further as well in terms of the framing.
Activity
Jack-Works commentedon Oct 18, 2026
Hi! Do you mean this: https://github.com/tc39/proposal-rm-builtin-subclassing ?
guybedford commentedon Oct 18, 2026
The subclassing here is not an issue as that still holds a GC ref to the view right.
The problem is restricting creating derived views that reference the underlying buffer directly even after the buffer property is hidden.
Jack-Works commentedon Oct 20, 2026
Thanks for the clarification! Just to make sure I understand correctly, is this a new orthogonal capability, right?
In the current proposal, creating a subarray is fine since it doesn't expand the accessible memory range or grant additional write permissions, and you're proposing is an additional ownership constraint that prevents creating another TypedArray referencing the same underlying memory, even if the new view doesn't extend the original view's accessible range or capabilities. Is that correct?
Are you focusing on disabling the aliasing (create another reference to the same memory), or limiting the lifetime (other reference may be fine, but they must not live longer than the original one), or both?
guybedford commentedon Oct 20, 2026
Exactly it's a new capability. My thinking is for managed memory that must be freed into a Wasm buffer, a JS finalizer on the view itself can be responsible for the Wasm free call, allowing the view to represent a zero copy owned JS buffer from Wasm, while supporting cleanup.