| 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: | bmalloc | Assignee: | 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
Saam Barati
2020-02-28 14:02:33 PST
Created attachment 392018 [details]
patch
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. Created attachment 392019 [details]
patch for landing
Comment on attachment 392019 [details] patch for landing Clearing flags on attachment: 392019 Committed r257662: <https://trac.webkit.org/changeset/257662> All reviewed patches have been landed. Closing bug. |