RESOLVED FIXED 208392
Clean up code with how we choose Gigacage sizes and whether or not to use Wasm fast memory 
https://bugs.webkit.org/show_bug.cgi?id=208392
Summary Clean up code with how we choose Gigacage sizes and whether or not to use Was...
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+
DetailsFormatted DiffDiff
patch for landing (3.23 KB, patch)
2020-02-28 14:12 PST, Saam Barati 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Saam Barati
Comment 1 2020-02-28 14:05:43 PST
Created attachment 392018 [details] patch
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
<rdar://problem/59907312>
Note You need to log in before you can comment on or make changes to this bug.