1784497 - Extend element segments to support GC types

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, task, P3)

Description

[Ryan Hunt [:rhunt]]

Element segments currently are hardcoded to only support ref.func $i or ref.null using elemFuncIndices [1]. When we extend constant expressions to include construction of GC objects in bug 1784156, this will start to become an issue as elem segments are filled with constant expressions which may now start to produce non-null and non-funcref typed values.

We initially can just limit element segment constant expressions to just 'ref.func or null' and add support for this in element segments once we need it.

There is an interesting question regarding when to evaluate the contents of an element segment. Right now we store func indices to represent 'ref.func $i', so there's no difference between evaluating lazily when a table.init happens or eagerly at instantiation. With general GC instructions, this is no longer the case. We may need to evaluate the contents of element segments eagerly during instantiation and then just copy the results when a table.init happens. This may imply two representations of ElemSegment, ModuleElemSegment and InstanceElemSegment (names TBD).

But again, it's not clear this is needed anytime soon. My feeling is that tables will not be used for GC objects anytime soon. Globals are a better fit.

[1] https://searchfox.org/mozilla-central/rev/6ec440e105c2b75d5cae9d34f957a2f85a106d54/js/src/wasm/WasmModuleTypes.h#408

Comment 1

[Ryan Hunt [:rhunt]]

I think to do this we definitely need a ModuleElemSegment and InstanceElemSegment. The existing ElemSegment can become ModuleElemSegment.

Right now ModuleElemSegment is an Uint32Vector elemFuncIndices. If we generalize it to support gc instructions, it really becomes a Vector<InitExpr>. I'm a bit concerned about the space overhead of this change for existing applications which can have large elem segments of just func indices, InitExpr is pretty large.

I think an easy way to keep this optimization would be to add a Vector<InitExpr> elemInitializers to ModuleSegment which is used only when !elemType.isFunc(), when elemType.isFunc() it continues to use elemFuncIndices.

One way we could implement InstanceElemSegment is just as a WasmArrayObject with element type equal to the elem segment's type. This would make array.new_elem basically equivalent to an array.copy. We would evaluate ModuleElemSegments to InstanceElemSegments during instantiation.

Another change we'll need to make is generalizing the decoding code in DecodeElemSection [1]. That function is really large, we probably should break it up into a separate DecodeElemSegment function.

[1] https://searchfox.org/mozilla-central/rev/2d65dbd85ca11309dc0c485a63393110ef800083/js/src/wasm/WasmValidate.cpp#2657-2715

Comment 2

[Ryan Hunt [:rhunt]]

Setting the assignee based on talking with Yury.

Comment 3

[Ben Visness [:bvisness]]

Attachment: Bug 1784497: Generalize element segments to store expressions. r=rhunt

Comment 4

[Ben Visness [:bvisness]]

Attachment: Bug 1784497: Create separate representation for InstanceElemSegment. r=rhunt

Depends on D182121

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ac6ac22ca529
Generalize element segments to store expressions. r=rhunt
https://hg.mozilla.org/integration/autoland/rev/e49cf503dff4
Create separate representation for InstanceElemSegment. r=rhunt

Comment 6

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/ac6ac22ca529
https://hg.mozilla.org/mozilla-central/rev/e49cf503dff4