Title: [111617] trunk/Source/_javascript_Core
- Revision
- 111617
- Author
- [email protected]
- Date
- 2012-03-21 16:16:40 -0700 (Wed, 21 Mar 2012)
Log Message
WTF::MetaAllocator has a weak vtable (discovered when building wtf as a static library)
https://bugs.webkit.org/show_bug.cgi?id=81838
Reviewed by Geoffrey Garen.
My understanding is that weak vtables happen when the compiler/linker cannot
determine which compilation unit should constain the vtable. In this case
because there were only pure virtual functions as well as an "inline"
virtual destructor (thus the virtual destructor was defined in many compilation
units). Since you can't actually "inline" a virtual function (it still has to
bounce through the vtable), the "inline" on this virutal destructor doesn't
actually help performance, and is only serving to confuse the compiler here.
I've moved the destructor implementation to the .cpp file, thus making
it clear to the compiler where the vtable should be stored, and solving the error.
* wtf/MetaAllocator.cpp:
(WTF::MetaAllocator::~MetaAllocator):
(WTF):
* wtf/MetaAllocator.h:
Modified Paths
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (111616 => 111617)
--- trunk/Source/_javascript_Core/ChangeLog 2012-03-21 22:59:36 UTC (rev 111616)
+++ trunk/Source/_javascript_Core/ChangeLog 2012-03-21 23:16:40 UTC (rev 111617)
@@ -1,3 +1,25 @@
+2012-03-21 Eric Seidel <[email protected]>
+
+ WTF::MetaAllocator has a weak vtable (discovered when building wtf as a static library)
+ https://bugs.webkit.org/show_bug.cgi?id=81838
+
+ Reviewed by Geoffrey Garen.
+
+ My understanding is that weak vtables happen when the compiler/linker cannot
+ determine which compilation unit should constain the vtable. In this case
+ because there were only pure virtual functions as well as an "inline"
+ virtual destructor (thus the virtual destructor was defined in many compilation
+ units). Since you can't actually "inline" a virtual function (it still has to
+ bounce through the vtable), the "inline" on this virutal destructor doesn't
+ actually help performance, and is only serving to confuse the compiler here.
+ I've moved the destructor implementation to the .cpp file, thus making
+ it clear to the compiler where the vtable should be stored, and solving the error.
+
+ * wtf/MetaAllocator.cpp:
+ (WTF::MetaAllocator::~MetaAllocator):
+ (WTF):
+ * wtf/MetaAllocator.h:
+
2012-03-20 Gavin Barraclough <[email protected]>
RegExpMatchesArray should not copy the ovector
Modified: trunk/Source/_javascript_Core/wtf/MetaAllocator.cpp (111616 => 111617)
--- trunk/Source/_javascript_Core/wtf/MetaAllocator.cpp 2012-03-21 22:59:36 UTC (rev 111616)
+++ trunk/Source/_javascript_Core/wtf/MetaAllocator.cpp 2012-03-21 23:16:40 UTC (rev 111617)
@@ -33,6 +33,20 @@
namespace WTF {
+MetaAllocator::~MetaAllocator()
+{
+ for (FreeSpaceNode* node = m_freeSpaceSizeMap.first(); node;) {
+ FreeSpaceNode* next = node->successor();
+ m_freeSpaceSizeMap.remove(node);
+ freeFreeSpaceNode(node);
+ node = next;
+ }
+ m_lock.Finalize();
+#ifndef NDEBUG
+ ASSERT(!m_mallocBalance);
+#endif
+}
+
void MetaAllocatorTracker::notify(MetaAllocatorHandle* handle)
{
m_allocations.insert(handle);
Modified: trunk/Source/_javascript_Core/wtf/MetaAllocator.h (111616 => 111617)
--- trunk/Source/_javascript_Core/wtf/MetaAllocator.h 2012-03-21 22:59:36 UTC (rev 111616)
+++ trunk/Source/_javascript_Core/wtf/MetaAllocator.h 2012-03-21 23:16:40 UTC (rev 111617)
@@ -196,20 +196,6 @@
#endif
};
-inline MetaAllocator::~MetaAllocator()
-{
- for (FreeSpaceNode* node = m_freeSpaceSizeMap.first(); node;) {
- FreeSpaceNode* next = node->successor();
- m_freeSpaceSizeMap.remove(node);
- freeFreeSpaceNode(node);
- node = next;
- }
- m_lock.Finalize();
-#ifndef NDEBUG
- ASSERT(!m_mallocBalance);
-#endif
-}
-
} // namespace WTF
#endif // WTF_MetaAllocator_h
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
