Title: [92217] trunk/Source/_javascript_Core
- Revision
- 92217
- Author
- fpi...@apple.com
- Date
- 2011-08-02 12:57:06 -0700 (Tue, 02 Aug 2011)
Log Message
JSC does a GC even when the heap still has free pages
https://bugs.webkit.org/show_bug.cgi?id=65445
Reviewed by Oliver Hunt.
If the high watermark is not reached, then we allocate new blocks as
before. If the current watermark does reach (or exceed) the high
watermark, then we check if there is a block on the free block pool.
If there is, we simply allocation from it. If there isn't, we
invoke a collectin as before. This effectively couples the elastic
scavenging to the collector's decision function. That is, if an
application rapidly varies its heap usage (sometimes using more and
sometimes less) then the collector will not thrash as it used to.
But if heap usage drops and stays low then the scavenger thread and
the GC will eventually reach a kind of consensus: the GC will set
the watermark low because of low heap usage, and the scavenger thread
will steadily eliminate pages from the free page pool, until the size
of the free pool is below the high watermark.
On command-line, this is neutral on SunSpider and Kraken and a 3% win
on V8. In browser, this is a 1% win on V8 and neutral on the other
two.
* heap/Heap.cpp:
(JSC::Heap::allocateSlowCase):
(JSC::Heap::allocateBlock):
* heap/Heap.h:
Modified Paths
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (92216 => 92217)
--- trunk/Source/_javascript_Core/ChangeLog 2011-08-02 19:50:06 UTC (rev 92216)
+++ trunk/Source/_javascript_Core/ChangeLog 2011-08-02 19:57:06 UTC (rev 92217)
@@ -1,3 +1,33 @@
+2011-08-02 Filip Pizlo <fpi...@apple.com>
+
+ JSC does a GC even when the heap still has free pages
+ https://bugs.webkit.org/show_bug.cgi?id=65445
+
+ Reviewed by Oliver Hunt.
+
+ If the high watermark is not reached, then we allocate new blocks as
+ before. If the current watermark does reach (or exceed) the high
+ watermark, then we check if there is a block on the free block pool.
+ If there is, we simply allocation from it. If there isn't, we
+ invoke a collectin as before. This effectively couples the elastic
+ scavenging to the collector's decision function. That is, if an
+ application rapidly varies its heap usage (sometimes using more and
+ sometimes less) then the collector will not thrash as it used to.
+ But if heap usage drops and stays low then the scavenger thread and
+ the GC will eventually reach a kind of consensus: the GC will set
+ the watermark low because of low heap usage, and the scavenger thread
+ will steadily eliminate pages from the free page pool, until the size
+ of the free pool is below the high watermark.
+
+ On command-line, this is neutral on SunSpider and Kraken and a 3% win
+ on V8. In browser, this is a 1% win on V8 and neutral on the other
+ two.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::allocateSlowCase):
+ (JSC::Heap::allocateBlock):
+ * heap/Heap.h:
+
2011-08-02 Jeff Miller <je...@apple.com>
Move WTF_USE_AVFOUNDATION from _javascript_Core/wtf/platform.h to WebCore/config.h
Modified: trunk/Source/_javascript_Core/heap/Heap.cpp (92216 => 92217)
--- trunk/Source/_javascript_Core/heap/Heap.cpp 2011-08-02 19:50:06 UTC (rev 92216)
+++ trunk/Source/_javascript_Core/heap/Heap.cpp 2011-08-02 19:57:06 UTC (rev 92217)
@@ -404,8 +404,16 @@
if (LIKELY(result != 0))
return result;
- if (m_newSpace.waterMark() < m_newSpace.highWaterMark() || !m_isSafeToCollect) {
- m_newSpace.addBlock(sizeClass, allocateBlock(sizeClass.cellSize));
+ AllocationEffort allocationEffort;
+
+ if (m_newSpace.waterMark() < m_newSpace.highWaterMark() || !m_isSafeToCollect)
+ allocationEffort = AllocationMustSucceed;
+ else
+ allocationEffort = AllocationCanFail;
+
+ MarkedBlock* block = allocateBlock(sizeClass.cellSize, allocationEffort);
+ if (block) {
+ m_newSpace.addBlock(sizeClass, block);
void* result = tryAllocate(sizeClass);
ASSERT(result);
return result;
@@ -420,7 +428,7 @@
ASSERT(m_newSpace.waterMark() < m_newSpace.highWaterMark());
- m_newSpace.addBlock(sizeClass, allocateBlock(sizeClass.cellSize));
+ m_newSpace.addBlock(sizeClass, allocateBlock(sizeClass.cellSize, AllocationMustSucceed));
result = tryAllocate(sizeClass);
ASSERT(result);
@@ -694,11 +702,14 @@
return true;
}
-MarkedBlock* Heap::allocateBlock(size_t cellSize)
+MarkedBlock* Heap::allocateBlock(size_t cellSize, Heap::AllocationEffort allocationEffort)
{
MarkedBlock* block;
#if !ENABLE(LAZY_BLOCK_FREEING)
+ if (allocationEffort == AllocationCanFail)
+ return 0;
+
block = MarkedBlock::create(this, cellSize);
#else
{
@@ -712,6 +723,8 @@
}
if (block)
block->initForCellSize(cellSize);
+ else if (allocationEffort == AllocationCanFail)
+ return 0;
else
block = MarkedBlock::create(this, cellSize);
#endif
Modified: trunk/Source/_javascript_Core/heap/Heap.h (92216 => 92217)
--- trunk/Source/_javascript_Core/heap/Heap.h 2011-08-02 19:50:06 UTC (rev 92216)
+++ trunk/Source/_javascript_Core/heap/Heap.h 2011-08-02 19:57:06 UTC (rev 92217)
@@ -124,13 +124,15 @@
static const size_t minExtraCost = 256;
static const size_t maxExtraCost = 1024 * 1024;
+
+ enum AllocationEffort { AllocationMustSucceed, AllocationCanFail };
bool isValidAllocation(size_t);
void reportExtraMemoryCostSlowCase(size_t);
void canonicalizeBlocks();
void resetAllocator();
- MarkedBlock* allocateBlock(size_t cellSize);
+ MarkedBlock* allocateBlock(size_t cellSize, AllocationEffort);
void freeBlocks(MarkedBlock*);
void clearMarks();
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
