fixed in r77025

Hey Xan, We've had to re-write the FixedVMPoolAllocator, to fix fragmentation problems. In the new implementation the type of the internal structure needs to change to support different sizes, which is going to increase the complexity of dynamically changing behavior depending whether overcommit is available. Since I'm not testing on Linux I've decided it best just remove this for now, and cap Linux to 32MB of JIT buffers on all platforms. Please feel free to look at reintroducing the dynamic check if you wish, I think it'll probably mean selecting at runtime between two sets of page tables - I'll leave this in your hands. cheers, G.

http://trac.webkit.org/changeset/77025 might have broken Leopard Intel Debug (Tests)

r77025 made js1_5/Regress/regress-159334.js fail on 64 bit Linux (GTK and Qt). It was rolled out by http://trac.webkit.org/changeset/77090 .

<rdar://problem/8935574>

js1_5/Regress/regress-159334.js tests calling a giant function.

I think the fix here will be to disable these tests on Linux. The problem is that Linux does not support VM overcommit, since on x86-64 we need to allocate all VM in a single allocation, we have two choices on x86-64 linux: (1) commit a huge amount of physical RAM / swap up front (2) opt not to be able to run crazily huge functions. I think we have to pick the latter. Will look at this tomorrow.

Actually, there are valid options, so I should leave this decision to the Linux folks. I'm going to roll us back to the state prior to 75709 (see bug #42756), which is to say that on x86-64 we require 1GB of VM to be allocated up front, so we will not necessarily be able to run on !swap !overcommit configurations. Someone with some skin in the game on Linux can choose between: (1) Requiring 1GB VM. This will lead to poor support for !swap !overcommit configurations. (2) Dropping to ~32MB VM for all Linux/x86-64 configurations - this will mean we are unable to run crazily large test cases. (3) Provide a compile time option to select between the above. (4) Provide a runtime option to select between the above. Relanded in r77145.

I'd suggest doing (2), since it's easier to keep a single, predictable configuration working and tested -- and the more complicated the Linux setup is, the less likely it is to stay working. In order to do (2), you'll also need to configure the Linux bot to skip js1_5/Regress/regress-159334.js.

(In reply to comment #9) > I'd suggest doing (2), since it's easier to keep a single, predictable configuration working and tested -- and the more complicated the Linux setup is, the less likely it is to stay working. In order to do (2), you'll also need to configure the Linux bot to skip js1_5/Regress/regress-159334.js. On the other hand it is sad that we are doing this in the setup theoretically more likely to have lots of memory available. It's up to figure out some sane alternative though, so it's OK to do that for the time being as far as I'm concerned.