[Webkit-unassigned] [Bug 218693] New: [JSC] Implement WebAssembly.Memory with shared

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=218693

            Bug ID: 218693
           Summary: [JSC] Implement WebAssembly.Memory with shared
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ysuzuki at apple.com

Key requirement is that WebAssembly.Memory can be shared, plus, it can be grown by any threads.
Interesting thing is that, how to propagate this updated information to the other threads.

For memory itself, we cannot use reallocated memory since while reallocating, the other thread can access the old one.
These old one's write can be discarded if we cannot copy this content to the new memory.
We should allocate the memory as pages if shared is specified (a.k.a. like, fast memory) and grow it with mprotect.
To make it available, when shared: true is specified, WebAssembly.Memory mandatorily requires "maximum" size. So we can just allocate this pages, and available only initial bytes, and keep the rest unusable.
When growing, we can just call mprotect to make it usable so that we can use grown memory without changing address => perfect.
Since we only allocates maximum pages, we do not need to have much VA. So, even in iOS, we can use it.

The second problem is that memory address and memory size are cached by WebAssembly.Instance. By using the above technique, we can make address frozen.
But size can be changed in the current mechanism, since this size is used for bound checking right now, plus, this is the active memory size which can be changed by mprotect.
There are two potential answers.

1. Let's do some dirty hack and propagate the size information *eventually* to the all threads by using VM trap mechanism.
2. Let's change the size's meaning of WebAssembly.Instance. We put max VA size here instead of currently available size. Since this includes non-active memory region in bound-checking mode, we will hit signal handler invocation. And then, we use signal handler to emit out-of-memory exception even for bound-checking mode too.

I think (2)'s option is viable.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201108/419dca09/attachment-0001.htm>