[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