FEAT: two-phase transactional aggregated heap operations #380

pbalcer opened this Issue Dec 22, 2016 · 0 comments


None yet
1 participant

pbalcer commented Dec 22, 2016

Two-phase transactional aggregated heap operations


Currently each TX_ALLOC performs an actual separate persistent memory allocation into the undo log vector. The first step of the allocation process is a volatile state reservation, followed by on average 5 cache flushes, 3 of which are related to the use of redo-log mechanism.
The issue with this approach is that the allocation time cost is upfront, which can sometimes inhibit the "allocate, initialize, publish" work flow proposed by some research papers (linked below). It also misses on an opportunity to aggregate all of the transactional allocations into a single redo log.


The proposal is to split the transactional allocation into two phases:

  • reservation, quick operation performed mostly on the transient state, performed at the time of tx_alloc call
  • publishing, performed at the pre-commit phase or once the number of reserved allocations reaches either a predefined threshold or the redo log maximum capacity.

The reservation phase would create the redo log entries into a single big redo log, and the publish phase would process the redo log, creating the undo log vector. This would both significantly reduce the cost of transactional allocations (when performed in bulk) as well as shift that cost to later in the transaction.

Due to the fact that this might lead to spikes in performance, users will be able to configure how often does the publishing phase happens.

API Changes

A CTL entry point that defines the frequency of publishing phase will be added:
Once the number of reserved allocations reaches the "max_reserved" value, the redo log will be processed and the mechanism will start over.

Implementation details




Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment