Is there a way to avoid the 16.8 MB RegisterFile memory usage?
On loading a first page (google.com) I am seeing two 8.4 MB RegisterFile memory allocations for a total of 16.8 MB. Unfortunately, we don't have this much memory to spare, and virtual memory doesn't exist on our platforms. I'm wondering if there is anyway around this, regardless of the performance. Is there a way to reduce this to, say, two 512K allocations? I don't care of JavaScript performance drops 10-fold as a result. First 8.4 MB allocation: WTF::fastMalloc(size_t n=8421376) KJS::RegisterFile::RegisterFile(size_t capacity=2097152, size_t maxGlobals=8192) KJS::Machine::Machine() KJS::JSGlobalData::JSGlobalData() KJS::JSGlobalData::threadInstance() WebCore::JSDOMWindowShell::operator new(unsigned int size=24) WebCore::ScriptController::initScript() . . . Second 8.4 MB allocation: WTF::fastMalloc(size_t n=8421376) KJS::RegisterFile::RegisterFile(size_t capacity=2097152, size_t maxGlobals=8192) KJS::Machine::Machine() KJS::JSGlobalData::JSGlobalData() KJS::JSGlobalData::sharedInstance() KJS::JSGlobalObject::init(KJS::JSObject* thisValue) KJS::JSGlobalObject::JSGlobalObject(KJS::JSValue* prototype, KJS::JSObject* globalThisValue) WebCore::JSDOMWindowBase::JSDOMWindowBase(KJS::JSObject*, WebCore::DOMWindow*, WebCore::JSDOMWindowShell*) WebCore::JSDOMWindow::JSDOMWindow(WebCore::DOMWindow* impl, WebCore::JSDOMWindowShell* shell) WebCore::JSDOMWindowShell::JSDOMWindowShell(WebCore::DOMWindow * domWindow) WebCore::ScriptController::initScript() . . . Thanks.
On Aug 25, 2008, at 1:09 AM, Paul Pedriana wrote:
On loading a first page (google.com) I am seeing two 8.4 MB RegisterFile memory allocations for a total of 16.8 MB. Unfortunately, we don't have this much memory to spare, and virtual memory doesn't exist on our platforms. I'm wondering if there is anyway around this, regardless of the performance. Is there a way to reduce this to, say, two 512K allocations? I don't care of JavaScript performance drops 10-fold as a result.
Which revision of WebKit are you using? The 8MB RegisterFile capacity was dropped to 2MB back in <http://trac.webkit.org/changeset/34966>. That revision should also indicate how you could further decrease the RegisterFile capacity. I'll let someone with greater understanding of the JSCore VM indicate the consequences of decreasing this value, if any. - Mark
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. Geoff
On Tue, Aug 26, 2008 at 12:04 AM, Geoffrey Garen <ggaren@apple.com> 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]
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 <ggaren@apple.com> 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
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 <ggaren@apple.com> 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
participants (6)
-
Cedric Vivier
-
Geoffrey Garen
-
Maciej Stachowiak
-
Mark Rowe
-
Oliver Hunt
-
Paul Pedriana