Bug 208392

Summary: Clean up code with how we choose Gigacage sizes and whether or not to use Wasm fast memory
Product: WebKit Reporter: Saam Barati <saam>
Component: bmallocAssignee: Saam Barati <saam>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, darin, ews-watchlist, fpizlo, ggaren, keith_miller, mark.lam, mjs, msaboff, sam, tzagallo, webkit-bug-importer, ysuzuki
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
patch
ysuzuki: review+
patch for landing none

Saam Barati
Reported 2020-02-28 14:02:33 PST
...
Attachments
patch (3.24 KB, patch)
2020-02-28 14:05 PST, Saam Barati
ysuzuki: review+
patch for landing (3.23 KB, patch)
2020-02-28 14:12 PST, Saam Barati
no flags
Saam Barati
Comment 1 2020-02-28 14:05:43 PST
Yusuke Suzuki
Comment 2 2020-02-28 14:06:58 PST
Comment on attachment 392018 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=392018&action=review r=me > Source/JavaScriptCore/runtime/OptionsList.h:462 > + v(Bool, useWebAssemblyFastMemory, WTF_OS_CONSTANT_EFFECTIVE_ADDRESS_WIDTH >= 48, Normal, "If true, we will try to use a 32-bit address space with a signal handler to bounds check wasm memory.") \ Use `OS_CONSTANT(EFFECTIVE_ADDRESS_WIDTH)` instead.
Saam Barati
Comment 3 2020-02-28 14:12:08 PST
Created attachment 392019 [details] patch for landing
WebKit Commit Bot
Comment 4 2020-02-28 15:59:31 PST
Comment on attachment 392019 [details] patch for landing Clearing flags on attachment: 392019 Committed r257662: <https://trac.webkit.org/changeset/257662>
WebKit Commit Bot
Comment 5 2020-02-28 15:59:33 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 6 2020-02-28 16:00:16 PST
Note You need to log in before you can comment on or make changes to this bug.