|
Thanks for the info about the smaller RegisterFile size; I'll try
reducing it for myself and see how it goes. The RegisterFile.h code has a to-do/fix-me comment for Win32 saying to switch from malloc to VirtualAlloc. FWIW, my vote would be to not make direct calls to OS memory functions within RegisterFile or WebKit in general, at least for non-Unix/Mac builds. Primarily this is because it makes assumptions about what the user wants to do or what the system can do which might not be true. Doing system level memory allocations also prevents the application from measuring memory usage and implementing heap validation. At the least, a user-overridable allocation function can be used and which defaults to using operator new (at least outside Unix variants). This would also have the benefit of allowing the code to work across all platforms out of the box. On Windows, VirtualAlloc isn't likely to buy much because AFAIK VirtualAlloc doesn't have the property whereby it commits pages on demand, though it's possible that a future version of Windows may do it. However, in the meantime if the user can implement these allocations then it's possible for a user to create a page protected heap that works like the Windows process stack and manually commit upon a page fault. With that approach you can also manually extend the mapped memory beyond the original VirtualAlloc size in case the memory requirement becomes huge. Thanks. Paul The RegisterFile is the amount of memory available on the JS stack, reducing it directly reduces the amount of stack, and hence recursion, that js code can do. That said, the RegisterFile allocation should result in delayed paging -- eg. it should only be reserving address space, and the OS won't actually allocate memory until we attempt to use it. At least if mmap exists and is usable.--Oliver On Aug 25, 2008, at 5:25 PM, Cedric Vivier wrote:On Tue, Aug 26, 2008 at 12:04 AM, Geoffrey Garen <[EMAIL PROTECTED]> wrote: |
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
