[Webkit-unassigned] [Bug 209236] REGRESSION(r249808): [GTK] Crash in JSC Config::permanentlyFreeze() on architecture ppc64el

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 19 18:26:36 PDT 2020


--- Comment #39 from Michael Catanzaro <mcatanzaro at gnome.org> ---
Here's an initial patch.

Mark, any idea what's up with WTF::pageSize() vs. WTF::vmPageSize()? They do the same thing on all platforms except iOS family, where pageSize() uses the userspace page size (16 KiB, vm_page_size) whereas vmPageSize() uses the kernel page size (4 KiB,  vm_kernel_page_size). That's a strange difference. At first I had implemented vmPageSize() for OS(UNIX), but eventually I realized I could just get rid of that because it's really only needed in ResourceUsageCocoa.cpp, and changed JSCConfig to use pageSize() rather than vmPageSize(). Should be fine for iOS family because roundUpToMultipleOf(4 KiB, 16 KiB) == roundUpToMultipleOf(4 KiB, 16 KiB) == 16 KiB. I wound up not touching vmPageSize() at all, but it seems really suspicious to me. There's also bmalloc::vmPageSize(), which is the same as WTF::pageSize(), i.e. on iOS bmalloc::vmPageSize() returns a different value than WTF::vmPageSize() because bmalloc uses the userspace value while WTF uses the kernel value.)

Behavior change: I reduced the size of JSCConfig from 16 KiB down to 4 KiB on macOS and most Linux architectures. I assume that makes sense because there's no reason for it to be any bigger than a single page, yes? I can be the hero who saved 12 KiB per web process?

Then I made no behavior change in MarkedBlock.h. I used std::max(16 * KiB, CeilingOnPageSize) there, which I assume that makes sense because any changes there would affect object fragmentation, which could have performance impacts. Didn't want to mess with that.

Oh, and I changed pageSize() to use sysconf(_SC_PAGESIZE) instead of getpagesize() just because that's deprecated. And added RELEASE_ASSERTs in pageSize().

Let's see if EWS likes it....

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200320/5874dc07/attachment-0001.htm>

More information about the webkit-unassigned mailing list