Posts tagged with 'memory'

We all like C++’s container classes such as maps. The main negative thing about them is persistance. Ending your process makes the data structure go away. If you want to store it, you need to write code to serialise it to disk and then deserialise it back to memory again when you need it. This is tedious work that has to be done over and over again.

It would be great if you could command STL containers to write their data to disk instead of memory. The reductions in application startup time alone would be welcomed by all. In addition most uses for small embedded databases such as SQLite would go away if you could just read stuff from persistent std::maps.

The standard does not provide for this because serialisation is a hard problem. But it turns out this is, in fact, possible to do today. The only tools you need are the standard library and basic standards conforming C++.

Before we get to the details, please note this warning from the society of responsible coding.

What follows is the single most evil piece of code I have ever written. Do not use it unless you understand the myriad of ways it can fail (and possibly not even then).

The basic problem is that C++ containers work only with memory but serialisation requires writing bytes to disk. The tried and true solution for this problem is memory mapped files. It is a technique where a certain portion of process’ memory is mapped to a backing file. Any changes to the memory layout will be written to the disk by the kernel. This gives us memory serialisation.

This is only half of the problem, though. STL containers and others allocate the memory they need through operator new. The way new works is implementation defined. It may give out addresses that are scattered around the memory space. We can’t mmap the entire address space because it would take too much space and serialise lots of stuff we don’t care about.

Fortunately C++ allows you to specify custom allocators for containers. An allocator is an object that does memory allocations for the object it is tied to. This indirection allows us to write our own allocator that gives out raw memory chunks from the mmapped memory area.

But there is still a problem. Since pointers refer to absolute memory locations we would need to have the mmapped memory area in the same location in every process that wants to use it. It turns out that you can enforce the address at which the memory mapping is to be done. This gives us an outline on how to achieve our goal.

create an empty file for backing (10 MB in this example)

mmap it in place

populate the data structure with objects allocated in the mmapped area

close creator program

start reader program, mmap the data and cast the root object into existance

First we declare the absolute memory address of the mmapping (it can be anything as long as it won’t overlap an existing allocation). The allocator itself is extremely simple, it just hands out memory offset bytes in the mapping and increments offset by the amount of bytes allocated (plus alignment). Deallocated memory is never actually freed, it remains unused (destructors are called, though). Last we have typedefs for our mmap backed containers.

Note in particular how we can specify the type as std::map<std::string, std::string> rather than the custom allocator version in the creator application. The output is this.

Sizeof map: 1.
Value of 'key': value

It may seem a bit anticlimactic, but what it does is quite powerful.

Extra evil bonus points

If this is not evil enough for you, just think about what other things can be achieved with this technique. As an example you can have the backing file mapped to multiple processes at the same time, in which case they all see changes live. This allows you to have things such as standard containers that are shared among processes.

If you read discussions on the Internet about memory allocation (and who doesn’t, really), one surprising tidbit that always comes up is that in Linux, malloc never returns null because the kernel does a thing called memory overcommit. This is easy to verify with a simple test application.

This app tries to malloc memory one byte at a time and writes to it. It keeps doing this until either malloc returns null or the process is killed by the OOM killer. When run, the latter happens. Thus we have now proved conclusively that malloc never returns null.

In this application we try to allocate a block of ever increasing size. If the allocation is successful, we release the block before trying to allocate a bigger one. This program does receive a null pointer from malloc.

When run on a machine with 16 GB of memory, the program will fail once the allocation grows to roughly 14 GB. I don’t know the exact reason for this, but it may be that the kernel reserves some part of the address space for itself and trying to allocate a chunk bigger than all remaining memory fails.

Summarizing: malloc under Linux can either return null or not and the non-null pointer you get back is either valid or invalid and there is no way to tell which one it is.

Many have asked me what’s been going on with the work on Ubuntu on the Nexus 7 recently. A lot of people put work into getting the raring images ready for public consumption. 12.10 worked great on the Nexus, but there were a few blockers on getting 13.04 to work as well. On this road among other things these issues were fixed:

A new onboard pre-release made it into 13.04 which fixes many bugs already and makes our on-screen keyboard a lot easier to use. Thanks a lot to the onboard team.

The new Unity stack got into raring, which is now automatically tested after commits and auto-released into 13.04. This is a huge milestone from the Unity team. Among the issues fixed was a nux problem, which constituted a blocker.

The new raring images use oem-config to present us with an installer window, where you can specify a user name, the wireless network you want to use and other bits.

Many many other issues were fixed as well.

Ubuntu on the Nexus 7

So what does this mean for you now? You can now very easily put Ubuntu 13.04 on your Nexus 7. It won’t need any additional PPA, it’s stock raring, you won’t have to reflash, but can just do your regular updates and enjoy the latest and greatest improvements day by day.

This is a huge achievement and will allow us to do better and more immediate testing and hacking on the device.

Hacking

One thing we want to improve on the Nexus 7 (and in Ubuntu in general) is memory consumption. Alex Chiang has put together some great blog posts on how to help with finding memory issues and debugging them. They are absolutely worth a read and an effort worth getting involved with. Here are the links:

If you want to make Ubuntu better and have a bit of a development background, be sure to check them out.

Meeting the team

Everybody who has been working on Ubuntu on the Nexus 7 has documented things on the wiki pages, so if you are excited about this, be sure head there first. Also does the team hang out in 24/7 in #ubuntu-arm on irc.freenode.net, so feel free to drop by, say Hi and get to know the others.