Bug 170227 - WebAssembly: add shell-only Memory mode helper
Summary: WebAssembly: add shell-only Memory mode helper
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: JF Bastien
URL:
Keywords:
Depends on:
Blocks: 159775
  Show dependency treegraph
 
Reported: 2017-03-28 21:48 PDT by JF Bastien
Modified: 2017-03-29 10:45 PDT (History)
8 users (show)

See Also:


Attachments
patch (8.89 KB, patch)
2017-03-28 21:50 PDT, JF Bastien
no flags Details | Formatted Diff | Diff
patch (9.50 KB, patch)
2017-03-28 22:22 PDT, JF Bastien
no flags Details | Formatted Diff | Diff
patch (11.26 KB, patch)
2017-03-29 09:19 PDT, JF Bastien
mark.lam: review+
buildbot: commit-queue-
Details | Formatted Diff | Diff
patch (18.16 KB, patch)
2017-03-29 10:30 PDT, JF Bastien
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.