Changeset 31061 in webkit for trunk/JavaScriptCore

Timestamp:

Mar 14, 2008, 12:05:28 PM (17 years ago)

Author:

[email protected]

Message:

Reviewed by Beth Dakin.

Fixed a few problems with Vector::shrinkCapacity that I noticed in testing.

• wtf/Vector.h: (WTF::VectorBufferBase::deallocateBuffer): Clear our m_buffer pointer when we deallocate m_buffer, in case we're not asked to reallocate a new buffer. (Otherwise, we would use a stale m_buffer if we were asked to perform any operations after shrinkCapacity was called.)

(WTF::VectorBuffer::allocateBuffer): Made VectorBuffer with inline
capacity aware that calls to allocateBuffer might be shrinks, rather
than grows, so we shouldn't allocate a new buffer on the heap unless
our inline buffer is too small.

(WTF::::shrinkCapacity): Call resize() instead of just setting m_size,
so destructors run. Call resize before reallocating the buffer to make
sure that we still have access to the objects we need to destroy. Call
moveOverlapping instead of move, since a call to allocateBuffer on an
inline buffer may produce identical storage.

Location:

trunk/JavaScriptCore

Files:

• ChangeLog (modified) (2 diffs)
• wtf/Vector.h (modified) (4 diffs)

trunk/JavaScriptCore/ChangeLog

@@ +1 @@
+2008-03-14  Geoffrey Garen  <[email protected]>
+
+        Reviewed by Beth Dakin.
+        
+        Fixed a few problems with Vector::shrinkCapacity that I noticed in testing.
+
+        * wtf/Vector.h:
+        (WTF::VectorBufferBase::deallocateBuffer): Clear our m_buffer pointer
+        when we deallocate m_buffer, in case we're not asked to reallocate a new
+        buffer. (Otherwise, we would use a stale m_buffer if we were asked to
+        perform any operations after shrinkCapacity was called.)
+        
+        (WTF::VectorBuffer::allocateBuffer): Made VectorBuffer with inline
+        capacity aware that calls to allocateBuffer might be shrinks, rather
+        than grows, so we shouldn't allocate a new buffer on the heap unless
+        our inline buffer is too small.
+        
+        (WTF::::shrinkCapacity): Call resize() instead of just setting m_size,
+        so destructors run. Call resize before reallocating the buffer to make
+        sure that we still have access to the objects we need to destroy. Call
+        moveOverlapping instead of move, since a call to allocateBuffer on an
+        inline buffer may produce identical storage.
+
 2008-03-14  Alexey Proskuryakov  <[email protected]>
 
@@ -223 +246 @@
         * JavaScriptCore.vcproj/testkjs/testkjs.vcproj:
 
-2008-03-09  Jürg Billeter  <[email protected]>
+2008-03-09  J¸rg Billeter  <[email protected]>
 
         Reviewed by Alp Toker.

trunk/JavaScriptCore/wtf/Vector.h

@@ -254 +254 @@
         void deallocateBuffer(T* bufferToDeallocate)
         {
+            if (m_buffer == bufferToDeallocate)
+                m_buffer = 0;
             fastFree(bufferToDeallocate);
         }
@@ -344 +346 @@
             : Base(inlineBuffer(), inlineCapacity)
         {
-            if (capacity > inlineCapacity)
-                allocateBuffer(capacity);
+            allocateBuffer(capacity);
         }
 
@@ -353 +354 @@
         }
 
-        using Base::allocateBuffer;
+        void allocateBuffer(size_t newCapacity)
+        {
+            if (newCapacity > inlineCapacity)
+                Base::allocateBuffer(newCapacity);
+        }
 
         void deallocateBuffer(T* bufferToDeallocate)
@@ -666 +671 @@
             return;
 
+        resize(min(m_size, newCapacity));
+
         T* oldBuffer = begin();
         if (newCapacity > 0) {
             T* oldEnd = end();
             m_buffer.allocateBuffer(newCapacity);
-            TypeOperations::move(oldBuffer, oldEnd, begin());
-        }
-        m_size = min(m_size, newCapacity);
+            TypeOperations::moveOverlapping(oldBuffer, oldEnd, begin());
+        }
+
         m_buffer.deallocateBuffer(oldBuffer);
     }