Bug 170227

Summary: WebAssembly: add shell-only Memory mode helper
Product: WebKit Reporter: JF Bastien <jfbastien>
Component: JavaScriptCoreAssignee: JF Bastien <jfbastien>
Status: RESOLVED FIXED    
Severity: Normal CC: buildbot, commit-queue, fpizlo, jfbastien, keith_miller, mark.lam, msaboff, sbarati
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 159775    
Attachments:
Description Flags
patch
none
patch
none
patch
mark.lam: review+, buildbot: commit-queue-
patch none

Description JF Bastien 2017-03-28 21:48:19 PDT
While hacking in JSC or testing the implementation, it's useful to be able to figure out which mode a Memory or an Instance's Memory is in.
Comment 1 JF Bastien 2017-03-28 21:50:30 PDT
Created attachment 305704 [details]
patch
Comment 2 JF Bastien 2017-03-28 22:22:51 PDT
Created attachment 305708 [details]
patch

Missing private export.
Comment 3 Keith Miller 2017-03-28 22:36:12 PDT
How do you plan to use this? I'm skeptical of writing tests that assert the memory mode they are in. It's not clear that the OS guarantees that we can get any number of Signaling memories, especially if the system is under memory pressure.
Comment 4 JF Bastien 2017-03-28 23:22:59 PDT
(In reply to Keith Miller from comment #3)
> How do you plan to use this? I'm skeptical of writing tests that assert the
> memory mode they are in. It's not clear that the OS guarantees that we can
> get any number of Signaling memories, especially if the system is under
> memory pressure.

I want to run some benchmarks and see which get fast memory, which don't. When I print out runtime numbers I can bin these differently.

Of course if I get zero Signaling or zero BoundsChecked, and I expected to get some, then I'll have to do something else. This tool won't solve that issue, it'll just make it apparent.
Comment 5 JF Bastien 2017-03-29 09:19:04 PDT
Created attachment 305745 [details]
patch

Also export Instance / Module s_info, which is used by jsc.cpp.
Comment 6 Mark Lam 2017-03-29 09:55:46 PDT
Comment on attachment 305745 [details]
patch

r=me
Comment 7 Mark Lam 2017-03-29 09:56:08 PDT
Please fix build failures before landing.
Comment 8 Build Bot 2017-03-29 09:56:55 PDT
Comment on attachment 305745 [details]
patch

Attachment 305745 [details] did not pass jsc-ews (mac):
Output: http://webkit-queues.webkit.org/results/3434349

New failing tests:
wasm.yaml/wasm/js-api/element.js.default-wasm
wasm.yaml/wasm/js-api/test_memory.js.default-wasm
wasm.yaml/wasm/function-tests/memory-section-and-import.js.default-wasm
Comment 9 JF Bastien 2017-03-29 10:30:30 PDT
Created attachment 305756 [details]
patch

The fix in assert.js un-hid actual failures in other tests, which I now fixed. They were just trying to match error strings which changed.
Comment 10 WebKit Commit Bot 2017-03-29 10:45:03 PDT
Comment on attachment 305756 [details]
patch

Clearing flags on attachment: 305756

Committed r214547: <http://trac.webkit.org/changeset/214547>
Comment 11 WebKit Commit Bot 2017-03-29 10:45:06 PDT
All reviewed patches have been landed.  Closing bug.