RESOLVED FIXED Bug 170227
WebAssembly: add shell-only Memory mode helper
https://bugs.webkit.org/show_bug.cgi?id=170227
Summary WebAssembly: add shell-only Memory mode helper
JF Bastien
Reported 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.
Attachments
patch (8.89 KB, patch)
2017-03-28 21:50 PDT, JF Bastien
no flags
patch (9.50 KB, patch)
2017-03-28 22:22 PDT, JF Bastien
no flags
patch (11.26 KB, patch)
2017-03-29 09:19 PDT, JF Bastien
mark.lam: review+
buildbot: commit-queue-
patch (18.16 KB, patch)
2017-03-29 10:30 PDT, JF Bastien
no flags
JF Bastien
Comment 1 2017-03-28 21:50:30 PDT
JF Bastien
Comment 2 2017-03-28 22:22:51 PDT
Created attachment 305708 [details] patch Missing private export.
Keith Miller
Comment 3 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.
JF Bastien
Comment 4 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.
JF Bastien
Comment 5 2017-03-29 09:19:04 PDT
Created attachment 305745 [details] patch Also export Instance / Module s_info, which is used by jsc.cpp.
Mark Lam
Comment 6 2017-03-29 09:55:46 PDT
Comment on attachment 305745 [details] patch r=me
Mark Lam
Comment 7 2017-03-29 09:56:08 PDT
Please fix build failures before landing.
Build Bot
Comment 8 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
JF Bastien
Comment 9 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.
WebKit Commit Bot
Comment 10 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>
WebKit Commit Bot
Comment 11 2017-03-29 10:45:06 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.