Fixed a redis-cli bug, was using free instead of zfree call

[redis.git] / zipmap.c

diff --git a/zipmap.c b/zipmap.c
index 8a07b388ed5aabb6af3cd83a4bc175d1a6bf6f7b..6c13f8062c62ddd981c11ce84d535da347a427a5 100644 (file)
--- a/zipmap.c
+++ b/zipmap.c
@@ -42,10 +42,11 @@
 
 /* Memory layout of a zipmap, for the map "foo" => "bar", "hello" => "world":
  *
- * <status><len>"foo"<len><free>"bar"<len>"hello"<len><free>"world"
+ * <zmlen><len>"foo"<len><free>"bar"<len>"hello"<len><free>"world"
  *
- * <status> is 1 byte status. Currently only 1 bit is used: if the least
- * significant bit is set, it means the zipmap needs to be defragmented.
+ * <zmlen> is 1 byte length that holds the current size of the zipmap.
+ * When the zipmap length is greater than or equal to 254, this value
+ * is not used and the zipmap needs to be traversed to find out the length.
  *
  * <len> is the length of the following string (key or value).
  * <len> lengths are encoded in a single value or in a 5 bytes value.
@@ -62,22 +63,15 @@
  * or even in order to add a key/value pair if it fits.
  *
  * <free> is always an unsigned 8 bit number, because if after an
- * update operation there are more than a few free bytes, they'll be converted
- * into empty space prefixed by the special value 254.
+ * update operation there are more than a few free bytes, the zipmap will be
+ * reallocated to make sure it is as small as possible.
  *
  * The most compact representation of the above two elements hash is actually:
  *
- * "\x00\x03foo\x03\x00bar\x05hello\x05\x00world\xff"
+ * "\x02\x03foo\x03\x00bar\x05hello\x05\x00world\xff"
  *
- * Empty space is marked using a 254 bytes + a <len> (coded as already
- * specified). The length includes the 254 bytes in the count and the
- * space taken by the <len> field. So for instance removing the "foo" key
- * from the zipmap above will lead to the following representation:
- *
- * "\x00\xfd\x10........\x05hello\x05\x00world\xff"
- *
- * Note that because empty space, keys, values, are all prefixed length
- * "objects", the lookup will take O(N) where N is the numeber of elements
+ * Note that because keys and values are prefixed length "objects",
+ * the lookup will take O(N) where N is the number of elements
  * in the zipmap and *not* the number of bytes needed to represent the zipmap.
  * This lowers the constant times considerably.
  */
@@ -92,7 +86,7 @@
 
 /* The following defines the max value for the <free> field described in the
  * comments above, that is, the max number of trailing bytes in a value. */
-#define ZIPMAP_VALUE_MAX_FREE 5
+#define ZIPMAP_VALUE_MAX_FREE 4
 
 /* The following macro returns the number of bytes needed to encode the length
  * for the integer value _l, that is, 1 byte for lengths < ZIPMAP_BIGLEN and
@@ -214,7 +208,7 @@ static inline unsigned char *zipmapResize(unsigned char *zm, unsigned int len) {
  * If 'update' is not NULL, *update is set to 1 if the key was
  * already preset, otherwise to 0. */
 unsigned char *zipmapSet(unsigned char *zm, unsigned char *key, unsigned int klen, unsigned char *val, unsigned int vlen, int *update) {
-    unsigned int zmlen;
+    unsigned int zmlen, offset;
     unsigned int freelen, reqlen = zipmapRequiredLength(klen,vlen);
     unsigned int empty, vempty;
     unsigned char *p;
@@ -236,27 +230,34 @@ unsigned char *zipmapSet(unsigned char *zm, unsigned char *key, unsigned int kle
         if (update) *update = 1;
         freelen = zipmapRawEntryLength(p);
         if (freelen < reqlen) {
-            /* Move remaining entries to the current position, so this
-             * pair can be appended. Note: the +1 in memmove is caused
-             * by the end-of-zipmap byte. */
-            memmove(p, p+freelen, zmlen-((p-zm)+freelen+1));
+            /* Store the offset of this key within the current zipmap, so
+             * it can be resized. Then, move the tail backwards so this
+             * pair fits at the current position. */
+            offset = p-zm;
             zm = zipmapResize(zm, zmlen-freelen+reqlen);
-            p = zm+zmlen-1-freelen;
-            zmlen = zmlen-1-freelen+reqlen;
+            p = zm+offset;
+
+            /* The +1 in the number of bytes to be moved is caused by the
+             * end-of-zipmap byte. Note: the *original* zmlen is used. */
+            memmove(p+reqlen, p+freelen, zmlen-(offset+freelen+1));
+            zmlen = zmlen-freelen+reqlen;
             freelen = reqlen;
         }
     }
 
-    /* Ok we have a suitable block where to write the new key/value
-     * entry. */
+    /* We now have a suitable block where the key/value entry can
+     * be written. If there is too much free space, move the tail
+     * of the zipmap a few bytes to the front and shrink the zipmap,
+     * as we want zipmaps to be very space efficient. */
     empty = freelen-reqlen;
-    /* If there is too much free space mark it as a free block instead
-     * of adding it as trailing empty space for the value, as we want
-     * zipmaps to be very space efficient. */
     if (empty >= ZIPMAP_VALUE_MAX_FREE) {
-        memmove(p+reqlen, p+freelen, zmlen-((p-zm)+freelen+1));
+        /* First, move the tail <empty> bytes to the front, then resize
+         * the zipmap to be <empty> bytes smaller. */
+        offset = p-zm;
+        memmove(p+reqlen, p+freelen, zmlen-(offset+freelen+1));
         zmlen -= empty;
         zm = zipmapResize(zm, zmlen);
+        p = zm+offset;
         vempty = 0;
     } else {
         vempty = empty;