NFX Memory Object Pile

Object Pile shifts the paradigm of .NET development as it eliminates the processing gaps caused by the GC. It provides a practical solution for consumption of heaps measured in 100s of gigabytes. Pile stores hundreds of millions of CLR objects in-process - a normal use-case! It is utilized in server applications via regular CLR object allocations on pile making Big Memory applications possible on a 100% managed runtime.

GET The Code

Apache 2.0; Get Commercial Support: Contact Us

Pile is:
  • Fast - staying in the multi-million ops/sec range with typical payloads
  • Convenient - use your .NET objects: structs, classes, polymorphism, arrays
  • Practical - when business changes - so does your model - Pile takes object graphs of any complexity*
  • Simple - native .NET API with 5 types to deal with
  • Layered - build your own data structures or use LocalCache server in-process
  • MMF Support - you can mirror memory to disk
Simple API:

    var person = new Person{Name="Frank Drebin", Occupation="Police Officer"};
    var piled = pile.Put(person);
    var got = pile.Get(piled) as Person;
    Console.WriteLine(got.Name); // "Frank Drebin"
GET Pile

    var userData = new SocialUser{.....};
    var tbl = cache.GetOrCreateTable("users");
    tbl.Put(userData.SocialID, userData);
    var requestedId = new SocialID(IDType.Twitter, 42376472343);
    var ageSec = 120;
    var user = tbl.Get(requestedId, maxAgeSec: ageSec) as SocialUser;
    var removed = tbl.Remove(requestedId);
GET Pile
  Apache 2.0 Open Source,
  We offer commercial support +1 (888) 507-1164

* - Pile does not support serialization of unmanaged pointers and delegates. Pile can serialize POCO object models of any complexity (recursive etc.), the classes do not even need to be decorated as [Serilalizable]. Pile supports any complex framework types which are serializable (i.e. Dictionary <>, ConcurrentDictionary <> with custom comparers)

Pile solves the notorious GC stalls problem which existed since the first days of managed memory model. Unfortunately, the GC blocking can not be eradicated completely - it is the price we have to pay for the higher-level memory model. In recent years there have been significant improvements in GC mechanisms see this MSDN blog post. The GC became less intrusive, and more informative, so we can now know about the upcoming blocking GC phase and try to divert traffic to a nearby server. This has helped many use-cases.

There is a number of systems, however, where GC remains problematic despite all of the improvements made in the runtime. It is a customary routine to use the out-of-box/process solutions such as Redis in such systems, however keep in mind that out-of-process stores still require serialization and transportation overhead.