How to implement Grid memory

In 10 years

In the future we will have Persistent memory to replace our nowadays RAM: MRAM, FERAM, and ReRAM

More implementations to come.

This is encouraging, but we need this memory today, not in 30 years.

Nowadays

We can create Grid memory with the current level of technology:

1. Using MMU we can create a linear address space directly mapped 1:1 onto SSD blocks.
2. RAM will be not considered a separate resource available to applications, instead it will be used to cache the most recently used SSD pages.
3. At power-off and/or on a regular basis we will flush modified virtual memory pages back to SDD.
4. At power-off we need to flush all not-yet-flushed dirty pages to preserve the correct memory state.
5. In the linear address space we created, we will organize a heap that allocates grid memory for objects, thread stacks and sections of machine code.

Legend:

• White RAM page – not-modified page
• Red RAM page – modified page
• Green arrow – page presented in RAM
• Red arrow – page that is to be loaded from SSD to RAM on first access
• Blue arrow – page to be saved on eviction or at data commit
• Grey arrow – page that can be dropped as no-op.

This figure demonstrates that:

• All CPU/GPU/TPU/DMA operations see the same linear address space – there are no separate “processes”
• Linear addresses are directly mapped to SSD addresses
• Randomly-chosen RAM pages are used to cache access to SSD page-sized blocks

This approach demonstrates that the OS kernel providing the Grid memory is the order of magnitude simpler than nowadays operation systems. It does not need to handle:

• process address space creation, management and IPC,
• files and file systems,
• device drivers (with exception of SSD device).

It could’ve been the simplest and smallest OS kernel ever.

BTW, the step 4 in the above list is not that trivial – it might use specialized hardware to prevent data loss on power-off, or it can employ a software-backed transactional mechanism. It is a topic for a separate discussion. But it’s doable.

Today

We don’t want to start implementation of the Grid as a new operating system for the following reasons:

• The main goal of the project is not to implement a grid itself, but to create a SilverDOM – a high-level abstraction, an environment build atop of the Grid memory.
• Debugging/redesigning/demoing the SilverDOM should not require people to install a new operation system kernel or meet a specific hardware requirements.
• Initially, the SilverDOM environment will be lacking many features and application packages, so it won’t be useful as a stand-alone OS or environment for years.

All these reasons suggest starting developing the SilverDOM not as a standalone OS but instead as an application that works inside existing OSes along with other applications.

So Minimal Viable Product could look like this:

Grid driver is a Linux/Windows/OsX… application which:

• Handles OS-specific life cycle.
• Allocates huge (configurable) address space portion at the fixed address and mmap it to a grid-file.
• All actual working code, thread stacks and objects-documents is contained in this grid file.
• Driver app provides API to communicate with GUI, sockets etc.

Even simpler approach that could be used in first demos/experiments:

• Driver app performs mmap for a grid-file, that contains heap with objects (not a code).
• Driver app, when application code changes, builds it using LLVM and reloads resulting SO/DLL
• Thread stacks are allocated outside of the grid-file.

This approach allows to use common SO/DLL format for the application code, thus utilizing the existing system toolchain for creating and debugging applications.

These variants of implementation of grid memory allow to quickly implement this memory inside existing OS and focus on creating the SilverDOM application infrastructure that is able to thrive in Grid.