Changeset 192721 in webkit
- Timestamp:
- Nov 20, 2015 8:40:40 PM (8 years ago)
- Location:
- trunk/Source/JavaScriptCore
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/Source/JavaScriptCore/ChangeLog
r192708 r192721 1 2015-11-20 Andreas Kling <akling@apple.com> 2 3 GC timers should carry on gracefully when Heap claims it grew from GC. 4 <https://webkit.org/b/151521> 5 6 Reviewed by Mark Lam. 7 8 TL;DR the Heap "extra memory" reporting APIs are hard to use 100% correctly 9 and GC scheduling shouldn't break if someone makes a mistake with it. 10 11 The JSC::Heap allows you to report an extra memory cost for any GC object. 12 This is reported first when allocating the memory, and then each time the 13 object is visited during the marking phase. 14 15 When reporting an allocation, it's added to the Heap's "bytes allocated in 16 this cycle" counter. This contributes to the computed heap size at the start 17 of a collection. 18 19 When visiting a GC object that reports extra memory, it's added to the Heap's 20 "extra memory visited in this collection" counter. This contributes to the 21 computed heap size at the end of a collection. 22 23 As you can see, this means that visiting more memory than we said we allocated 24 can lead to the Heap thinking it's bigger after a collection than it was before. 25 26 Clients of this API do some sketchy things to compute costs, for instance 27 StringImpl cost is determined by dividing the number of bytes used for the 28 characters, and dividing it by the StringImpl's ref count. Since a JSString 29 could be backed by any StringImpl, any code that modifies a StringImpl's 30 ref count during collection will change the extra memory reported by all 31 JSString objects that wrap that StringImpl. 32 33 So anyways... 34 35 The object death rate, which is the basis for when to schedule the next 36 collection is computed like so: 37 38 deathRate = (sizeBeforeGC - sizeAfterGC) / sizeBeforeGC 39 40 This patch adds a safety mechanism that returns a zero death rate when the Heap 41 claims it grew from collection. 42 43 * heap/EdenGCActivityCallback.cpp: 44 (JSC::EdenGCActivityCallback::deathRate): 45 * heap/FullGCActivityCallback.cpp: 46 (JSC::FullGCActivityCallback::deathRate): 47 1 48 2015-11-20 Mark Lam <mark.lam@apple.com> 2 49 -
trunk/Source/JavaScriptCore/heap/EdenGCActivityCallback.cpp
r165940 r192721 55 55 if (!sizeBefore) 56 56 return 1.0; 57 if (sizeAfter > sizeBefore) { 58 // GC caused the heap to grow(!) 59 // This could happen if the we visited more extra memory than was reported allocated. 60 // We don't return a negative death rate, since that would schedule the next GC in the past. 61 return 0; 62 } 57 63 return static_cast<double>(sizeBefore - sizeAfter) / static_cast<double>(sizeBefore); 58 64 } -
trunk/Source/JavaScriptCore/heap/FullGCActivityCallback.cpp
r185387 r192721 71 71 if (!sizeBefore) 72 72 return 1.0; 73 if (sizeAfter > sizeBefore) { 74 // GC caused the heap to grow(!) 75 // This could happen if the we visited more extra memory than was reported allocated. 76 // We don't return a negative death rate, since that would schedule the next GC in the past. 77 return 0; 78 } 73 79 return static_cast<double>(sizeBefore - sizeAfter) / static_cast<double>(sizeBefore); 74 80 }
Note: See TracChangeset
for help on using the changeset viewer.