cuckoohash_map.reserve() greater than DEFAULT_SIZE allocates new array without freeing old(?) about libcuckoo HOT 1 CLOSED

So the reason we can't immediately free the old table during expansion time is that other threads may be running at the same time, and may be reading from that old table. If we free it in the expansion thread, the other threads could read invalid memory, when they resume. You'll see in the snapshot_and_lock_* methods, that we retry the whole thing if the table_info pointer changed before and after taking locks, but even still, we can't risk taking locks on a free'd TableInfo.

Therefore, we add the old table to a backlog, and try deleting it during resize, when no thread's hazard pointer is set to the old table.

That being said, we should be freeing the old table if there is no other thread looking at the table. We were not doing this, because the hazard pointer of the expansion thread was set to the old table, but I just pushed a commit (c87c193), that fixes this.

Now you should see in the unmodified count_freq:
Calling cuckoohash_map with hp 16
allocating 2^ 16 buckets
Calling cuckoohash_map with hp 22
allocating 2^ 22 buckets
de-allocating table with 2^ 16 buckets
...
de-allocating table with 2^ 22 buckets

Thanks for investigating!

from libcuckoo.