bitcoin/bitcoin — pull request #1699 by laanwj (2012-08-22 09:50:41+00:00)
Title: Handle locked pages more robustly (Fixes issue #1462)

I've investigated issue #1462 and in my experiments, the memory allocation pattern with a many transient objects almost guarantees that after the initialization of bitcoin **only one** of the pages is actually locked. This means that most of the keying material can end up in swap.

I considered two ways to address this:
1) A special memory pool (using boost::pool) of locked pages
2) Keep track of which pages are locked with a lock count

I first tried (1), but it ended up non-optimal. boost::pool is very wasteful with tiny objects (in this case, char), as the minimum chunk size seems to be the pointer size, resulting in a blow-up of 8× on 64 bit architectures. As locked pages are a limited resource, this should be avoided.

So I went with the second alternative. This solution is also easier to test than a full-blown custom memory pool. I've added an autotester.