RESOLVED FIXED 127152
CodeBlockSet should be generational
https://bugs.webkit.org/show_bug.cgi?id=127152
Summary CodeBlockSet should be generational
Mark Hahnenberg
Reported 2014-01-16 17:05:21 PST
This is a big overhead during EdenCollections. We should think about how we can generationalize our CodeBlock lifetimes.
Attachments
Patch (18.09 KB, patch)
2014-01-30 12:14 PST, Mark Hahnenberg
no flags
Patch (21.09 KB, patch)
2014-03-31 16:16 PDT, Mark Hahnenberg
no flags
Patch (21.42 KB, patch)
2014-03-31 16:23 PDT, Mark Hahnenberg
no flags
Final patch (20.58 KB, patch)
2014-04-02 14:08 PDT, Mark Hahnenberg
no flags
Mark Hahnenberg
Comment 1 2014-01-30 12:14:13 PST
Geoffrey Garen
Comment 2 2014-01-30 12:33:55 PST
Comment on attachment 222707 [details] Patch r=me
Mark Hahnenberg
Comment 3 2014-01-30 16:09:14 PST
(In reply to comment #1) > Created an attachment (id=222707) [details] > Patch Hmm, I think this patch has issues. The correctness of the weakReferenceHarvester stuff in which CodeBlocks participate is dependent on visiting all marked CodeBlocks during a collection. Otherwise we won't propagate liveness for all the things that hang off of CodeBlock that need it. Another alternative is to just ignore all new CodeBlocks (i.e. auto-promote, pretenure, etc.). We'd still have to visit them to LUB value profiles.
Mark Hahnenberg
Comment 4 2014-03-31 16:16:19 PDT
Mark Hahnenberg
Comment 5 2014-03-31 16:23:06 PDT
Geoffrey Garen
Comment 6 2014-03-31 16:49:30 PDT
Comment on attachment 228216 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=228216&action=review r=me > Source/JavaScriptCore/bytecode/CodeBlock.h:1004 > + // During EdenCollections all CodeBlocks that are visited are assumed to be live. Would be nice to explain our reasoning here: It's probably cheaper to assume liveness, and we don't want to worry about write barrier subtleties required by the mutually weak liveness methodology. > Source/JavaScriptCore/heap/CodeBlockSet.cpp:71 > +void CodeBlockSet::clearAllMarks() > { > - for (CodeBlock* codeBlock : m_set) { > + promoteYoungCodeBlocks(); > + for (CodeBlock* codeBlock : m_oldCodeBlocks) { > codeBlock->m_mayBeExecuting = false; > codeBlock->m_visitAggregateHasBeenCalled = false; > } > } It feels strange for "clearAllMarks" to promote. And might this get us into a bad state if deleteAllCompiledCode is called at the start of an eden collection? Similarly strange, though less so, for deleteUnmarkedAndUnreferenced to promote. Can we make the caller promote instead? For example, Heap::deleteAllCompiledCode could run only during full collections, and Heap::markRoots could eagerly promote code blocks before full collections and lazily promote code blocks after eden collections. Or, Heap::resetAllocators() could promote code blocks unconditionally, and Heap::deleteAllCompiledCode could run after Heap::resetAllocators().
Geoffrey Garen
Comment 7 2014-04-02 12:19:03 PDT
Comment on attachment 228216 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=228216&action=review > Source/JavaScriptCore/heap/CodeBlockSet.cpp:135 > + m_oldCodeBlocks.remove(codeBlock); Needs early return.
Mark Hahnenberg
Comment 8 2014-04-02 14:08:44 PDT
Created attachment 228428 [details] Final patch
Mark Hahnenberg
Comment 9 2014-04-02 14:10:31 PDT
Comment on attachment 228428 [details] Final patch View in context: https://bugs.webkit.org/attachment.cgi?id=228428&action=review > Source/JavaScriptCore/bytecode/CodeBlock.h:151 > + template <typename Functor> void forEachRelatedCodeBlock(Functor&& functor) > + { > + Functor f(std::forward<Functor>(functor)); > + Vector<CodeBlock*, 4> codeBlocks; > + codeBlocks.append(this); > + > + while (!codeBlocks.isEmpty()) { > + CodeBlock* currentCodeBlock = codeBlocks.takeLast(); > + f(currentCodeBlock); > + > + if (CodeBlock* alternative = currentCodeBlock->alternative()) > + codeBlocks.append(alternative); > + if (CodeBlock* osrEntryBlock = currentCodeBlock->specialOSREntryBlockOrNull()) > + codeBlocks.append(osrEntryBlock); > + } > + } I had to add handling of the OSR entry block along with the alternative blocks. To make it more general, I turned it into a DFS of a DAG. There's no defense against cycles.
Geoffrey Garen
Comment 10 2014-04-02 16:17:46 PDT
Comment on attachment 228428 [details] Final patch r=me
WebKit Commit Bot
Comment 11 2014-04-02 16:50:52 PDT
Comment on attachment 228428 [details] Final patch Clearing flags on attachment: 228428 Committed r166678: <http://trac.webkit.org/changeset/166678>
WebKit Commit Bot
Comment 12 2014-04-02 16:50:56 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.