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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 30 14:37:36 PDT 2011


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





--- Comment #12 from Filip Pizlo <fpizlo at apple.com>  2011-08-30 14:37:36 PST ---
(In reply to comment #11)
> +// 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>.

This sounds good, I'll give it a shot.

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



More information about the webkit-unassigned mailing list