On Aug 26, 2008, at 12:24 AM, Paul Pedriana wrote:
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.
WebKit porters are welcome to choose whatever is appropriate for their
port, taking into account system assumptions. For users of the public
API, I think explicit allocation control would be kind of dodgy.
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.
It doesn't demand-commit but it does let you separate commit and
reserve, which means you could decommit when exiting JS execution for
instance.
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.
If the memory requirement gets that big there's probably runaway
recursion so we're ok with killing the computation.
- Maciej
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:
If you want the RegisterFile to be 512K, just change its size to
512K.
You can even deallocate it after JavaScript finishes executing, if
that helps.
I am curious as well as Mark, what are the consequences of
decreasing
(or increasing) this value ? [besides the memory usage of course]
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
