Re: [Monotone-devel] oprofile data for mtn 0.37.

[Jack Lloyd]

On Wed, Mar 12, 2008 at 05:19:50PM -0400, Zack Weinberg wrote:

> This would be my choice, being the most efficient option for a
> single-threaded program like Monotone.

There are some interesting implications in this choice WRT memory:

The library needs to allocate space somehow. Assuming we don't just
switch wholesale to the STL and use new/malloc for everything, each
memory object will need to be given access to an allocator explicitly
(since there will be no global env for it to get a reference to one).

So code will look like

Allocator_Malloc default_alloc;

MemoryVector<byte> f(default_alloc, 100);
func_using_memory_allocation(default_alloc);

Allocator_MallocAndMlock locking_alloc;

ClassNeedingMemoryAllocation c(locking_alloc);

Pros:

  The MemoryBuffer/MemoryVector/SecureVector split goes away; each
   memory buffer allocates storage from (and deallocates to) the
   allocator passed to it at construction.

  Fairly fine grained control of what is/is not locked. Individual
  allocators could be constructed with limits, allowing you to bound
  (to some extent, at least; nothing preventing out of control usage
  in STL containers, etc) the amount of memory used by a particular
  computation.

Cons:

  Rather verbose

  Will require API changes if implementation changes (eg, a function
  that didn't used to need a MemoryRegion nows does, all the callers
  have to be updated)

The notes of the EROS space bank are interesting reading in this
context. http://www.eros-os.org/design-notes/SpaceBank.html

-Jack