The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,468 other followers

Vintage Dave is working on a new multithreaded memory manager for Delphi that does not have a global lock

Posted by jpluimers on 2013/06/19

The comment thread at via [WayBack] The Oracle at Delphi » Give in to the ARC side (now at [WayBackplace 1 and [WayBack] 2) is very interesting.

So soon after writing a StackOverflow [WayBackanswer on Delphi Memory Managers yesterday, [WayBack] this one by [WayBack] David M (aka vintagedave) caught my eye:

This is unannounced at the moment, but I am working on a new memory manager which does not have a global lock, and is designed for multithreaded usage, including cases where memory is allocated in one thread and freed in another, and many threads are allocating and freeing at once. It also uses a more secure design than FastMM4, which may be important for world-facing code, eg web servers. It’s a personal project which I have not yet announced, but if you are interested (Allen, Guenther, others) please feel free to contact me at

I wonder if it is better than the multithreaded Delphi memory managers I mentioned in the answer:

As a side note:

One of the reasons for using FastMM is the excellent debugging capabilities. It looks like – though not free – DDDebug extends this a lot!

I found it in Wanted: live leak detection for FastMM – and [WayBackTURBU Tech » Blog Archive » Wanted: live leak detection for FastMM.


via The Oracle at Delphi » Give in to the ARC side.

9 Responses to “Vintage Dave is working on a new multithreaded memory manager for Delphi that does not have a global lock”

  1. thaddy said

    Andre’s code (scalemm) is also based on the ideas from Ivo (topmm). Both were direct collegues of mine. Algorithmically they are pretty much the same. Topmm is still running on very, very large systems. It is also – on purpose – more defensive in its approach. IIRC they worked together at some point in discussing their approaches.
    Anyway, for historical purposes: they belong to the same family.

  2. Hi Jeroen,

    I’m glad this memory manager sounds interesting enough to blog about! I have already got a couple of emails from interested people.

    I have to point out it is not finished yet and I don’t have a concrete idea of how it behaves in the real world. I cannot make any guarantees at all: I started writing it purely for my own interest. In fact, I have planned to take a couple of days off work in order to focus on it, and I hope to have a rough alpha version ready soon. I can state that in the single-threaded case, I don’t expect it to meet the performance of FastMM for three reasons: (a), it’s currently written in pure Pascal, so does not benefit from assembler-optimised code the way FastMM does; (b) it’s early days and is not yet well optimised, though I’ve been measuring and keeping an eye on performance when writing to try to avoid doing anything completely idiotic; (c) it has a few deliberate design decisions that are features that have a side-effect of making it slightly slower. These are for security reasons.

    I have two goals for this memory manager, based on my view of the current state of computing: multithreaded coding is now normal and so the MM needs to be designed for that, not only for singlethreaded coding; and that security is important, and where a MM can be designed to lessen the chances of hacks, it should. (Delphi-coded programs, including things like web services, are no more immune to or unlikely to be attacked than the same program written in C++.)

    There are several security improvement techniques currently implemented in my MM, and two that make performance differences are that memory header information is not stored adjacent to the memory allocation it refers to, unlike (I think) FastMM, and that memory is always cleared on free rather than leaving the data in memory. There are several others that have no performance impact.

    Interestingly some of these can actually improve performance, too. Storing the memory header info elsewhere slows down allocations and frees, but may speed up other code since the CPU cache is not polluted with (generally useless) data. Allocating and freeing are relatively rare operations to perform on memory: generally you read or write it. When a cache pulls in a block of memory, any memory header info included in that is not usually something that will be used, so decreases the amount of the cache holding useful data.

    I will try to get the code into a useful alpha state and post a blog article soon. Meanwhile, don’t get your expectations too high – this is the first MM I’ve written, it could be terrible ;)

    • jpluimers said

      Seeing your comment in the ARC thread was too much of a coincidence to let it pass by unnoticed (:

      I’ve been interested in memory managers ever since I wrote the KORSAKOV memory allocation logger in the Turbo Pascal 7 / Delphi 1 era.

      Knowing that multi-threaded code can be mind bogglingly difficult, and we now live in the ubiquitous processor core era makes me keep an eye open for anything in that area.

      So thanks in advance for your effort. And please contact some of the developers of other MMs: I’m sure that will benefit the Delphi world at large.


    • Torbins said

      Fill with patterns only where you can’t mark region of memory as PAGE_NOACCESS. This will trigger AV sooner.

  3. Eric said

    Another contender is the NexusDB MM
    I haven’t tried their latest versions, but it was already a very good contender during the FastCode Memory Manager challenges.

    • jpluimers said

      Thanks! I totally forgot about this one (:

    • Eivind said

      Please note that the version of NexusDB MM being sold separately is now superceded by the version that comes with the NexusDB database product. The new MM is not being sold separately though. It is (like Dave is planning) designed to have minimum locking and scales very well in multithread scenarios.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: