[Webkit-unassigned] [Bug 61137] [BSD] OSAllocator::reserveUncommitted eagerly commits memory on BSD?

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=61137





--- Comment #8 from Gavin Barraclough <barraclough at apple.com>  2012-09-17 13:50:24 PST ---
(In reply to comment #7)
> And i still don't understand why X86_64 allocates 1Gb, while other archs (i386, powerpc....) will allocate 32Mb. Why is that change X86_64 only, if not for the failing regress tests in bug 53401 ?

The fixed allocator is only used on X86-64, and when running on iOS.  On all other CPUs and platforms we use the on-demand allocator.  The on-demand allocator allocates memory at the point it needs it, and frees it when it is done.

The on-demand allocator may allocate memory anywhere in the VM space, and this is a problem for x86-64, since relative branches have a range of +/- 2Gb.  If the on-demand allocator were to allocate two blocks of memory for use by the JIT more than 2Gb apart, linking could fail.

This is why instead we perform a single VM allocation, and commit/decommit subregions, so we can ensure a degree of locality within VM space.  The 1Gb size is intended to be more than one might possibly ever need for JIT code, whilst still a minuscule fraction of the x86-64 address space.  You are certainly welcome to drop this cap on OpenBSD, but I wouldn't recommend this as a solution, since the JIT isn't the only place we use this model of eagerly allocating VM space & commiting subregions on demand (e.g. we do something similar for the JS program's stack).  I'd recommend that finding a way to decouple memory commit from VM allocation (e.g. Matthew Dempsky's proposal in bug #61137) is going to be a much more satisfactory solution for you in the long run.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.