Design and implementation

The Wear-leveling-aware Sliding Counter

We propose wear-leveling-aware sliding counters to substitute for the vulnerable regular counters in the header table. As illustrated in Figure 3, we divide the 64-bit area into a 4-bit metadata region and a 60-bit sliding region. Figure 3 (a) shows the initial state of a sliding counter, of which the highest counting block is the 8th block in the counting region. When , each counting block will be moved to their left block. The highest counting block will finally reach the border of the counting region, as shown in Figure 3 (b). As shown in Figure 3 (c), we invert the direction of these counting blocks. To be specific, the serial number of the lowest counting block is 7, while that of the highest counting is 14. For i from 1 to 4, we swap each pair of (i+6)th and (15-i)th counting blocks. The direction bit is set to 0, indicating the direction of movements is to the right. As a consequence, the packing order of these counting blocks has reversed, in which the high blocks occupy the previous low blocks and vice versa. Subsequently, as shown in Figure 3 (d), the counting blocks move to the right as the counter value increases, opposite to the previous direction of movement.

The Copy-free Growth Mechanism

The WFPM bypasses the sorting process to conduct insertions without extra write activities. As illustrated in Figure 4, WFPM traverses the header table in descending order to fetch the order of items in transactions. When encountering an item that also appears in the transactions, we search down the tree from root to keep track of the pattern. Once inserting a new item into the tree, we create a new node with an initialized sliding counter. After processing the whole transaction, we only add one to the value of the last sliding counter, akin to the lazy counter mechanism in EvFP-Tree.

The Sorted Hash Walk

The PevFP-Tree has failed to fully take advantages of the counted frequencies of items. We construct a sorted hash walk mechanism to minimize the overhead of traversing the pointers in hash walks. As demonstrated in Figure 5, when inserting a new item pointer to the linked list in a hash table, we compare the frequency of the inserted item with that of items in the linked list. Finally, the new item pointer will be linked just after the older one with a larger frequency. Consequently, the item pointers are linked in descending order according to their frequencies, which provides fast accesses to most frequent items in the search down process.