Dynamic growth of slab pool for concurrent_map

[Nicolas-Iskos]

Modifications were made to SlabHash's concurrent_map as well as SlabAlloc to support dynamic growth of the device-side pool allocator used to extend slab lists.

In the SlabHash implementation currently available on the master branch, the number of slabs in the device-side slab pool is fixed (to 1GB). Consequently, the total memory footprint of the slab hash is fixed during run time. The code in this PR allows the number of slabs in the pool to increase dynamically during run time. Specifically, ConcurrentMap's buildBulk and buildBulkWithUniqueKeys determine whether the upcoming insertion batch will cause the structure to exceed a user-configurable threshold load factor. If so, new super blocks are added to the slab pool via cudaMalloc such that the structure's total memory footprint (sum of sizes of the base slabs and slab pool) doubles. Insertion then proceeds as normal. This allows the slab hash to continually grow its total memory footprint until device memory is exhausted.

gpu_hash_table has 3 new parameters (with default values). First, there are two template parameters for the number of memory blocks and number of super blocks with which to initialize the SlabAlloc, allowing the user to configure the initial size of the slab pool. Next, there is a threshold load factor argument which allows the user to configure how much of the SlabHash's total memory footprint can be occupied by key-value pairs before the slab pool is grown to double the total memory footprint.