• mhahnenberg@apple.com's avatar
    GC Activity Callback timer should be based on how much has been allocated since the last collection · 98daed04
    mhahnenberg@apple.com authored
    Reviewed by Geoffrey Garen.
    The desired behavior for the GC timer is to collect at some point in the future, 
    regardless of how little we've allocated. A secondary goal, which is almost if not 
    as important, is for the timer to collect sooner if there is the potential to 
    collect a greater amount of memory. Conversely, as we allocate more memory we'd 
    like to reduce the delay to the next collection. If we're allocating quickly enough, 
    the timer should be preempted in favor of a normal allocation-triggered collection. 
    If allocation were to slow or stop, we'd like the timer to be able to opportunistically 
    run a collection without us having to allocate to the hard limit set by the Heap.
    This type of policy can be described in terms of the amount of CPU we are willing 
    to dedicate to reclaim a single MB of memory. For example, we might be willing to 
    dedicate 1% of our CPU to reclaim 1 MB. We base our CPU usage off of the length of 
    the last collection, e.g. if our last collection took 1ms, we would want to wait about 
    100ms before running another collection to reclaim 1 MB. These constants should be 
    tune-able, e.g. 0.1% CPU = 1 MB vs. 1% CPU = 1 MB vs. 10% CPU = 1 MB.
    * API/JSBase.cpp: Use the new reportAbandonedObjectGraph.
    * API/JSContextRef.cpp: Ditto.
    * heap/Heap.cpp:
    (JSC::Heap::reportAbandonedObjectGraph): Similar to reportExtraMemoryCost. Clients call
    this function to notify the Heap that some unknown number of JSC objects might have just 
    been abandoned and are now garbage. The Heap might schedule a new collection timer based 
    on this notification.
    (JSC::Heap::collect): Renamed m_lastFullGCSize to the less confusing m_sizeAfterLastCollect.
    * heap/Heap.h:
    * heap/MarkedAllocator.h:
    (JSC::MarkedAllocator::zapFreeList): Fixed a bug in zapFreeList that failed to nullify the 
    current allocator's FreeList once zapping was complete.
    * runtime/GCActivityCallback.cpp: Removed didAbandonObjectGraph because it was replaced by 
    * runtime/GCActivityCallback.h:
    * runtime/GCActivityCallbackCF.cpp: Refactored the GC timer code so that we now schedule the 
    timer based on how much we have allocated since the last collection up to a certain amount. 
    We use the length of the previous GC to try to keep our total cost of opportunistic timer-triggered
    collections around 1% of the CPU per MB of garbage we expect to reclaim up to a maximum of 5 MB.
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@115156 268f45cc-cd09-0410-ab3c-d52691b4dbfc
GCActivityCallback.cpp 1.93 KB