The JSC GC has an elastic notion of free memory, where free blocks left over from a previous garbage collection are steadily returned to the OS provided that the application does not experience a subsequent heap usage spike that would need those blocks again. But the GC does not leverage this as well as it could. It separately maintains a watermark limit for invoking collection. This limit is independent of the number of free pages. Thus, if an application experiences a memory usage peak where the heap is grown, and then memory usage dips resulting in a lower watermark, then the heap will be in the following awkward state: the free block pool will still have blocks available for immediate use in allocations, but the collector will insist on running anyway. Ideally, the elasticity of the free block pool should be coupled to the GC's decision function for when to invoke collection, so that we don't do full collections when there is still free memory available.
Created attachment 102476 [details] the patch
Comment on attachment 102476 [details] the patch Clearing flags on attachment: 102476 Committed r92217: <http://trac.webkit.org/changeset/92217>
All reviewed patches have been landed. Closing bug.