[WASM-References] Add support for memory.fill

• Component: WebAssembly
• Status: RESOLVED FIXED

[Dmitry]

[WASM-References] Add support for memory.fill

[Dmitry]

Created attachment 416145 [details]
Patch

[EWS Watchlist]

This patch modifies one of the wasm.json files. Please ensure that any changes in one have been mirrored to the other. You can find the wasm.json files at "Source/JavaScriptCore/wasm/wasm.json" and "JSTests/wasm/wasm.json".

[Yusuke Suzuki]

Comment on attachment 416145 [details]
Patch

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

Looks good. Some comments.

> Source/JavaScriptCore/ChangeLog:8
> +        Added spec tests and unreachable tests for memory.fill.

Can you put this to JSTests/ChangeLog side?

> Source/JavaScriptCore/wasm/WasmMemory.cpp:624
> +        auto locker = holdLock(m_handle->lock());

I don't think we need this locking. When size is updated, mprotect is already done (because mprotect has memory barrier).
So, if `if (offset + count > m_handle->size())` pass, then we can just perform this without taking a lock.
So, I think we can just remove `doMemoryFill` function, and merge it into `Memory::fill`.

> Source/JavaScriptCore/wasm/WasmMemory.cpp:633
> +    if ((unsafeOffset < 0) || (unsafeCount < 0))
> +        return false;

Is it correct? I'm looking into https://webassembly.github.io/bulk-memory-operations/core/exec/instructions.html#exec-memory-fill, but I cannot find the corresponding thing.
Should we just handle unsafeOffset and unsafeCount as uint32_t instead?

> Source/JavaScriptCore/wasm/WasmSlowPaths.cpp:387
> +    int32_t dstAddress = READ(instruction.m_dstAddress).unboxedInt32();
> +    int32_t targetValue = READ(instruction.m_targetValue).unboxedInt32();
> +    int32_t count = READ(instruction.m_count).unboxedInt32();

If they should be handled as uint32, let's add unboxedUInt32 and use it (this is just `static_cast<uint32_t>(unboxedInt32())`).

> JSTests/ChangeLog:10
> +        Add support for memory.fill from ref-types spec.
> +        memory.fill sets all bytes in a memory region to a given byte:
> +        https://webassembly.github.io/reference-types/core/syntax/instructions.html#memory-instructions.

Can you put this to JavaScriptCore/ChangeLog side?

[Yusuke Suzuki]

Comment on attachment 416145 [details]
Patch

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

>> Source/JavaScriptCore/wasm/WasmMemory.cpp:624
>> +        auto locker = holdLock(m_handle->lock());
> 
> I don't think we need this locking. When size is updated, mprotect is already done (because mprotect has memory barrier).
> So, if `if (offset + count > m_handle->size())` pass, then we can just perform this without taking a lock.
> So, I think we can just remove `doMemoryFill` function, and merge it into `Memory::fill`.

Note that, if the memory mode is MemorySharingMode::Shared, underlying memory never gets replaced. mprotect will just extend it if memory grows.

[Dmitry]

Created attachment 416226 [details]
Patch

[Yusuke Suzuki]

Comment on attachment 416226 [details]
Patch

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

r=me with comment.

> Source/JavaScriptCore/wasm/WasmOperations.cpp:641
> +JSC_DEFINE_JIT_OPERATION(operationWasmMemoryFill, bool, (Instance* instance, uint32_t dstAddress, int32_t targetValue, uint32_t count))

Change `int32_t targetValue` to `uint32_t`.

> Source/JavaScriptCore/wasm/WasmOperations.h:64
> +JSC_DECLARE_JIT_OPERATION(operationWasmMemoryFill, bool, (Instance*, uint32_t dstAddress, int32_t targetValue, uint32_t count));

Ditto.

[Dmitry]

Created attachment 416233 [details]
Patch

[EWS]

Committed r270855: <https://trac.webkit.org/changeset/270855>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 416233 [details].

[Radar WebKit Bug Importer]

<rdar://problem/72349990>