[Webkit-unassigned] [Bug 118733] Javascript JIT still allocates 2GB of memory on x86-64 Linux

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from Török Edwin <edwin+webkit at etorok.net>  2013-07-16 09:25:00 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > > 32Mb is also vastly too small to successfully jit large pieces of JS so i'll assume that there were no perf tests run on this patch either.
> > 
> > Right, I have tested this only with Qt/KDE, where JIT performance doesn't really matter (in fact I'd be perfectly happy with disabling the JIT for it).
> >
> 
> Have you talked to any other Qt embedders? 
> 
> > I haven't checked how the allocation code works, but won't it allocate more pools when it runs out of the 32MB?
> 
> No.  The whole point of the FixedVMPool is that there is a single region of the address space in which all hit compiled code goes, this allows us to guarantee that all jumps are within the 32bit range allowed by a direct PC relative branch

My patch uses MAP_32BIT to guarantee that jumps are within 32-bit range.

> 
> > 
> > I've chosen 32MB because that is what the 32-bit code uses, but if a larger value would be more appropriate then both should be updated.
> > 
> 
> Desktop 32-bit does not use the FixedVMPool, I think the only 32bit platform that uses it is iOS.
> 
> 
> > > 
> > > I think the correct fix here is to find out how linux GCs reserve address space without having the VM allocate physical backing memory.
> > 
> > There is a MAP_NORESERVE on the allocation but that doesn't seem to do what its supposed to: the OOM killer kicks in and starts killing applications once KWin+plasma-desktop+other applications exceed my physical RAM (8GB).
> > If I run the patched libqt4-script (which has the patched javascriptcore), then the memory usage of KDE is no longer >2GB, and the OOM killer never kicks in.
> > 
> > Reserving 2GB of VIRT, for a feature that is not critical for the application is not really nice...
> 
> Reserving 2gig of address space when there are terabytes (exabytes?) of address space available should be fine.  JSC and FastMalloc both make extensive use of reserved but unused address space, this seems like something where we need to know exactly what needs to happen to get linux to do the right thing (I refuse to believe that the linux VM can't handle this given that even windows can)

I'll try to write some standalone testcases with mmap to see what happens.
I'm running Linux 3.10.1, it could be a regression kernel-side.

In general its better to not overcommit, unless you have to. In this case I think the 2GB reservation can be worked around by using MAP_32BIT, so it is not an absolute requirement to overcommit by that much.

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