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

Reviewed by Geoff Garen.

Currently, in steady state (i.e. a constant amount of live GC 
memory with a constant rate of allocation) assuming we've just 
finished a collection with X live blocks in CopiedSpace, we 
increase our working set by X blocks in CopiedSpace with each 
collection we perform. This is due to the fact that we allocate 
until we run out of free blocks to use in the Heap before we 
consider whether we should run a collection. 

In the longer term, this issue will be mostly resolved by 
implementing quick release for the CopiedSpace. In the shorter 
term, we should change our policy to check whether we should 
allocate before trying to use a free block from the Heap. We 
can change our policy to something more appropriate once we 
have implemented quick release.

This change should also have the convenient side effect of 
reducing the variance in GC-heavy tests (e.g. v8-splay) due 
to fact that we are doing less VM allocation during copying 
collection. Overall, this patch is performance neutral across 
the benchmarks we track.

* heap/CopiedSpace.cpp: 
(JSC::CopiedSpace::getFreshBlock): Shuffle the request from the BlockAllocator
around so that we only do it if the block request must succeed 
i.e. after we've already checked whether we should do a collection.
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCase): Ditto.
(JSC::MarkedAllocator::allocateBlock): We no longer have a failure mode in this 
function because by the time we've called it, we've already checked whether we 
should run a collection so there's no point in returning null.
* heap/MarkedAllocator.h: Removing old arguments from function declaration.
(MarkedAllocator):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116484 268f45cc-cd09-0410-ab3c-d52691b4dbfc