[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jack Lloyd
Subject: Re: [Monotone-devel] oprofile data for mtn 0.37.
Date: Thu, 13 Mar 2008 10:38:15 -0400
User-agent: Mutt/1.5.11

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);

Allocator_MallocAndMlock locking_alloc;

ClassNeedingMemoryAllocation c(locking_alloc);


  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


  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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]