[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 #7 from Oliver Hunt <oliver at apple.com>  2013-07-16 10:08:40 PST ---
(In reply to comment #5)
> (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.

As long as the FixedVMPool is 2gig or less you get that guarantee.  MAP_32BIT is irrelevant to that.

Please read my replies, I said _No_.  The FixedVMPool allocator means we have a _fixed_ pool.  There is only one allocation.  There are no more after that.  All JIT code goes into that one allocation.  If that region is exhausted, and we're unable to reclaim sufficient space we will just drop our generated code at link time and fall back to the interpreter.

> 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.

What? MAP_32BIT is not an answer here.

Do you understand what this code is doing?  Your references to MAP_32BIT are confusing me.

My understanding of MAP_32BIT are that it is a linux flag to force page allocation in the low 4 gig of the 64 bit address space, that's all.  Is my understanding of that behavior correct?

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