Hello community, here is the log from the commit of package libwebkit for openSUSE:11.4 checked in at Tue Oct 25 22:56:12 CEST 2011.
-------- --- old-versions/11.4/all/libwebkit/libwebkit.changes 2011-01-17 10:10:59.000000000 +0100 +++ 11.4/libwebkit/libwebkit.changes 2011-08-04 19:29:36.000000000 +0200 @@ -1,0 +2,7 @@ +Thu Aug 4 19:05:57 CEST 2011 - [email protected] + +- Add upstream patch that reduces the initial vm allocation to 32 MB + and increases that later only when overcommit is possible (i.e. swap + available) (bnc#710242). + +------------------------------------------------------------------- Package does not exist at destination yet. Using Fallback old-versions/11.4/all/libwebkit Destination is old-versions/11.4/UPDATES/all/libwebkit calling whatdependson for 11.4-i586 New: ---- libwebkit-reduce_up_front_allocation.patch ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ libwebkit.spec ++++++ --- /var/tmp/diff_new_pack.zzWzZG/_old 2011-10-25 22:54:52.000000000 +0200 +++ /var/tmp/diff_new_pack.zzWzZG/_new 2011-10-25 22:54:52.000000000 +0200 @@ -20,13 +20,15 @@ Name: libwebkit Summary: Library for rendering web content, GTK+ Port Version: 1.3.10 -Release: 2 +Release: 6.<RELEASE7> # FIXME: check if make stamp-po is still needed in %build, see https://bugs.webkit.org/show_bug.cgi?id=50612 (last checked: 1.3.7) License: LGPLv2.0 ; LGPLv2.0+ Group: Development/Libraries/C and C++ Url: http://webkit.org/ Source: webkit-%{version}.tar.bz2 Source1: baselibs.conf +# PATCH-FIX-UPSTREAM libwebkit-reduce_up_front_allocation.patch webkit-bug#42765 [email protected] -- Allocate 32M instead of 2G up front +Patch0: libwebkit-reduce_up_front_allocation.patch BuildRequires: bison BuildRequires: enchant-devel BuildRequires: flex @@ -112,6 +114,7 @@ %lang_package -n libwebkitgtk2 %prep %setup -q -n webkit-%{version} +%patch0 %build %ifarch ppc64 ++++++ libwebkit-reduce_up_front_allocation.patch ++++++ >From b26806bc90a23d5e29f597d710e6b9dbfb4694cb Mon Sep 17 00:00:00 2001 From: Xan Lopez <[email protected]> Date: Wed, 12 Jan 2011 23:25:23 +0100 Subject: [PATCH] 2011-01-12 Xan Lopez <[email protected]> Reviewed by NOBODY (OOPS!). JIT requires VM overcommit (particularly on x86-64), Linux does not by default support this without swap? https://bugs.webkit.org/show_bug.cgi?id=42756 The FixedVMPool Allocator does not work well on systems where allocating very large amounts of memory upfront is not reasonable, like Linux without overcommit enabled. As a workaround, on Linux, default to the values used in embedded environments (in the MB range), and only jump to the GB range if we detect at runtime that overcommit is enabled. Should fix crashes on Linux/x86_64 with less than 3 or 4GB of RAM. * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC::FixedVMPoolAllocator::free): use new variables for VM pool size and coalesce limit. (JSC::ExecutableAllocator::isValid): swap the variables from embedded to generic values at runtime, on linux, if overcommit is enabled. (JSC::ExecutableAllocator::underMemoryPressure): use new variables for VM pool size and coalesce limit. --- Source/JavaScriptCore/ChangeLog | 24 ++++++++++ .../jit/ExecutableAllocatorFixedVMPool.cpp | 49 ++++++++++++++++---- 2 files changed, 63 insertions(+), 10 deletions(-) Index: Source/JavaScriptCore/ChangeLog =================================================================== --- Source/JavaScriptCore/ChangeLog.orig 2011-01-11 02:07:11.000000000 +0100 +++ Source/JavaScriptCore/ChangeLog 2011-08-04 13:11:32.020662517 +0200 @@ -1,3 +1,27 @@ +2011-01-12 Xan Lopez <[email protected]> + + Reviewed by NOBODY (OOPS!). + + JIT requires VM overcommit (particularly on x86-64), Linux does not by default support this without swap? + https://bugs.webkit.org/show_bug.cgi?id=42756 + + The FixedVMPool Allocator does not work well on systems where + allocating very large amounts of memory upfront is not reasonable, + like Linux without overcommit enabled. As a workaround, on Linux, + default to the values used in embedded environments (in the MB + range), and only jump to the GB range if we detect at runtime that + overcommit is enabled. Should fix crashes on Linux/x86_64 with + less than 3 or 4GB of RAM. + + * jit/ExecutableAllocatorFixedVMPool.cpp: + (JSC::FixedVMPoolAllocator::free): use new variables for VM pool + size and coalesce limit. + (JSC::ExecutableAllocator::isValid): swap the variables from + embedded to generic values at runtime, on linux, if overcommit is + enabled. + (JSC::ExecutableAllocator::underMemoryPressure): use new variables + for VM pool size and coalesce limit. + 2011-01-10 Daniel Bates <[email protected]> Reviewed by Martin Robinson. Index: Source/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp =================================================================== --- Source/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp.orig 2011-01-03 23:55:02.000000000 +0100 +++ Source/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp 2011-08-04 13:08:29.311233800 +0200 @@ -38,14 +38,29 @@ #include <wtf/PageReservation.h> #include <wtf/VMTags.h> -#if CPU(X86_64) - // These limits suitable on 64-bit platforms (particularly x86-64, where we require all jumps to have a 2Gb max range). - #define VM_POOL_SIZE (2u * 1024u * 1024u * 1024u) // 2Gb - #define COALESCE_LIMIT (16u * 1024u * 1024u) // 16Mb +#if OS(LINUX) +#include <stdio.h> +#endif + +static const unsigned vmPoolSizeGeneric = 2u * 1024u * 1024u * 1024u; // 2Gb +static const unsigned coalesceLimitGeneric = 16u * 1024u * 1024u; // 16Mb + +static const unsigned vmPoolSizeEmbedded = 32u * 1024u * 1024u; // 32Mb +static const unsigned coalesceLimitEmbedded = 4u * 1024u * 1024u; // 4Mb + +#if CPU(X86_64) && !OS(LINUX) +// These limits suitable on 64-bit platforms (particularly x86-64, +// where we require all jumps to have a 2Gb max range). We don't +// enable this by default on Linux, since it needs overcommit and +// distros commonly disable that feature. We'll check the value +// for the overcommit feature at runtime and re-assign the Generic +// values if it's enabled. +static unsigned vmPoolSize = vmPoolSizeGeneric; // 2Gb +static unsigned coalesceLimit = coalesceLimitGeneric; // 16Mb #else // These limits are hopefully sensible on embedded platforms. - #define VM_POOL_SIZE (32u * 1024u * 1024u) // 32Mb - #define COALESCE_LIMIT (4u * 1024u * 1024u) // 4Mb +static unsigned vmPoolSize = vmPoolSizeEmbedded; // 32Mb +static unsigned coalesceLimit = coalesceLimitEmbedded; // 4Mb #endif using namespace WTF; @@ -315,7 +330,7 @@ public: // 16MB of allocations have been freed, sweep m_freeList // coalescing any neighboring fragments. m_countFreedSinceLastCoalesce += size; - if (m_countFreedSinceLastCoalesce >= COALESCE_LIMIT) { + if (m_countFreedSinceLastCoalesce >= coalesceLimit) { m_countFreedSinceLastCoalesce = 0; coalesceFreeSpace(); } @@ -436,8 +451,22 @@ static size_t allocatedCount = 0; bool ExecutableAllocator::isValid() const { SpinLockHolder lock_holder(&spinlock); - if (!allocator) - allocator = new FixedVMPoolAllocator(JIT_ALLOCATOR_LARGE_ALLOC_SIZE, VM_POOL_SIZE); + if (!allocator) { +#if OS(LINUX) + FILE* fp = fopen("/proc/sys/vm/overcommit_memory", "r"); + if (fp) { + unsigned overcommit = 0; + fscanf(fp, "%u", &overcommit); + if (overcommit == 1) { + vmPoolSize = vmPoolSizeGeneric; // 2Gb + coalesceLimit = coalesceLimitGeneric; // 16Mb + } + + fclose(fp); + } +#endif + allocator = new FixedVMPoolAllocator(JIT_ALLOCATOR_LARGE_ALLOC_SIZE, vmPoolSize); + } return allocator->isValid(); } @@ -445,7 +474,7 @@ bool ExecutableAllocator::underMemoryPre { // Technically we should take the spin lock here, but we don't care if we get stale data. // This is only really a heuristic anyway. - return allocatedCount > (VM_POOL_SIZE / 2); + return allocatedCount > (vmPoolSize / 2); } ExecutablePool::Allocation ExecutablePool::systemAlloc(size_t size) continue with "q"... Remember to have fun... -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
