[Webkit-unassigned] [Bug 67176] JavaScriptCore does not have tiered compilation

[bugzilla-daemon at webkit.org]

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





--- Comment #11 from Geoffrey Garen <ggaren at apple.com>  2011-08-30 14:35:57 PST ---
+// Finally, it differs from SentinelLinkedList by ensuring that the
+// sentinels only have next/prev pointers instead of the full contents of
+// the node structure. This makes DoublyLinkedSentinelList great for cases
+// where the nodes are large.

Sorry, didn't finish reading and see this comment.

> SentinelLinkedList would result in inlining two copies of CallLinkInfo into CodeBlock. 

What we definitely don't want is two classes with similar-sounding names that don't distinguish what's different between them. "DoublyLinkedSentinelList" isn't a very good way to distinguish vs "SentinelLinkedList", since they're both doubly linked, and it doesn't say what's actually different between them (the inlining of the full node vs just prev/next pointers).

We also probably don't want two different implementations of very similar algorithms, if we can avoid it.

To solve this problem, how about templatizing the existing SentinelLinkedList to be SentinelLinkedList<T, Node=SentinelLinkedListNode<T> >, to allow clients to specialize as necessary for a class that doesn't inherit from SentinelLinkedListNode? (Internally, SentinelLinkedList would only deal in Node*, but when returning a Node* to the client, it would static_cast to T*.)

Then, HandleHeap would use SentinelLinkedList<HandleHeap::Node, HandleHeap::Node>, and this patch would use SentinelLinkedList<CallLinkInfo>.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.