This is just a 'what if'/theoretical post with no current application.

Inspired by a talk about the advantages of range's over iterators in the stl, in my spare time I've been writing a 'stl' like library (a few containers and algorithms) that primarily uses ranges over iterators. Its been an interesting learning experience, and for the most part works. One thing I've disliked about the stl is allocators and I've been contemplating various alternatives.

Lately I've been reading about advances in non-volatile memory. Now we may have, in the near future, no hard drives; in that the ram is essentially the hard drive. And this got me thinking. If all ram were non-volatile, and there essentially was no hard drive, how would this change how we approached data management when programming? Clearly there would still be the stack, and temporary/scratch data, but it still brings up some interesting questions on how we manage data. How do we efficiently manage permanent data structures? Can permanent data structures become the norm? The current stl containers are clearly not designed to be portable, relocatable, or permanent, in any way. How would this affect iterators, and ranges? Pointers?

So with this in mind, I was wondering how I would write containers/allocators that would handle these things efficiently. My first thoughts went to the old x86 protected mode, which had segmentation. By having separate heaps or segments, you could have a container (or containers) on a given heap, and as long as the heap identifiers didn't change between program executions you have essentially portable and relocatable (to an extent) data structures. With a 64-bit pointer, having the high 16 bits be a 'segment selector', still gives the low 48-bits for an 'offset' (256 terrabytes seems large enough). Might need some sort of look-up table as x64 systems don't support segments in hardware. Also numeric ids are not always easy to work with, in theory you'd want to give the heaps names or other sensible identifiers.

Anyways at this point there are dozens different ideas, each with varying pro and cons. So, if you could re-write the stl containers/allocators, what would you do? Is it worth it or not? Can we support some more capabilities? What are the trade-offs?

probably it will go similar to what happened with Flash:

it started out mostly as memory-like (used for firmware / ROM);

then it generally ended up used mostly like it were an HDD;

or both at the same time (one part of the space is used as the ROM, and the rest like it were an HDD, *).

*: this isn't really all that uncommon in consumer electronics, then you can have a single Flash chip for everything.

at this point, most likely, nearly any kind of non-volatile storage will be made to look like it were an HDD, maybe with memory-mapped files thrown into the mix (a common historical way of doing non-volatile memory areas was via memory-mapping files). little else ultimately ends up being done as otherwise people will have to change their software, and this is generally a much bigger problem than making any new technology look/behave like an older technology.

"what about using it for persistent processes?..."

most likely not directly, OS developers would probably use it more for a faster form of "hibernate" or "sleep mode" or similar, and all your processes still need to be rebooted whenever the OS restarts.

"why not just do like Plan 9 or similar and allow processes to exist independently of the instance of the OS kernel which spawned it?..."

response: "what sort of crazy talk is this?!..."

otherwise, we could have such bizarre wackiness as being able to reboot the OS kernel when you update drivers or similar without forcing the user to exit and later restart all their apps. or, hell, even maybe you could "freeze" processes and simply move them out onto the HDD until the next time the user interacts with them.

then again, file-based storage tends to work out better than persistent process or persistent-memory in general.

like, with persistence, you end up with all of these ugly problems (memory fragmentation and/or leaks, memory damage due to bugs, ...), and it is easier typically to develop software with an implicit assumption that the user will need to exit and restart eventually (than any such issues "magically fix themselves").

it is sort of like the matter of shared memory vs explicit network protocols:

shared memory might seem nice, like, "wow, we can just share this data directly over the network and gloss over how it all works", but then you get all these ugly subtle issues, like memory timing/synchronization issues, version issues ("what if we change a structure layout somewhere?"), as well as ugly inter-op issues ("what if another application needs to interact?"), and security issues ("how do we prevent code from messing with data which doesn't belong to it?"), ...

so, ultimately, it tends to work out better just to send messages over a socket or similar.

You're probably right, in that its more hassle in most cases than its worth.