 Good day, ladies and gentlemen. Not a lot of ladies here, but still. There is a lot of operating systems around us. I'll try to describe the way that led me to the idea of this operating system so that it is very unusual. So I hope that you will understand the way I thought to came to this point. The idea was that traditional composite kernel operating systems are more or less outdated and the world around us tried to move to the microkernel operating systems and all of the microkernel projects that started at the start of this century there was a lot of problems with the inter-process communications. If you have the microkernel operating systems, you break down the system into the service working in separate address spaces, then you have to communicate with some kind of IPC between the services. If you break down the system in a real small services, which is an idea basically. Then you have a lot of communications. The user program calls one service. This service breaks down the call into several calls to the second service and so on and so on. And the overhead for the communications is huge. So the question was, do we really have to break down the code into separate address spaces? What's the idea? The idea is simple. We want to protect code. We want to protect different services, one from the other. The usual way to protect is based on the Unix paradigm, the separate address space. Can we do it in some other way? Actually yes. If the language, the basic virtual processor, our system works at forbids you to convert anything to a pointer, then you don't have to protect anything with the different address spaces. You cannot just produce a pointer for example from integer. Then you cannot access any memory, you just have no pointer too. Actually, Java virtual machine and some .NET virtual machine based on the same idea. So the next step was let's build an operating system around the virtual machine, which protects the memory this way as I described. And you can get rid of the inter-process communications completely. Your components can communicate by just calling one another with just a pointer to the object. The next question was, well, if we bring such an operating system, build it, in a usual way, we'll start services as a processes. They communicate with pointers, just calling one another. But the next problem is that if the service is not yet started but you try to communicate with it, the service is just not there. You're calling into the empty space. So the next question was, I think, quite unusual. In every traditional operating system, the process stops when the operating system kernel stops. Do we really have to require the process to stop when the operating system stops? The real answer is no. All the world the process living is is operating system and operating system can hide from the process, from the user space the fact that the kernel is rebooting. The easiest way to hide it is to build the, well, I'm not in sync with the presentation, but well, I believe it's okay. I'll get in sync later. So if we build the huge virtual address space which is persistent memory, then the programs living in this huge persistent memory just cannot imagine that there is something wrong around. When the system stops, it seamlessly saves all the state of this memory to the disk. And when it starts, it rebuilds all the space and programs just continue to run. Is it easy? The question is, if our system stops abruptly, somebody just pulls out the plug from the receptacle and system turns off or some hardware more functions, we have to build the world which saves the state frequently and doesn't take a lot of resources to do that. Well, I'll try to change to the next slide. Why not microkernel? I can ask it. So think of this persistent memory space having the size of usual disk so that it's not 100 megabytes, not 1,000 megabytes, maybe terabytes. Saving 1 terabyte to the disk is impossible in one moment and doing it frequently is impossible. But usually, how usual problem works, the big address space is divided into two parts. One is a working set which is modified frequently in the memory. And second part is usually can be mapped to the disk, but the difference between the memory state and disk state doesn't exist. Like code, when you bring it to the memory, there is no difference between the page in memory and page on the disk. So we don't have to save it. Actually, it is possible to build an operating system, which frequently, I mean once in a minute or even frequently, once in a second depending on the size and memory requirements of the process, saves all the state of the running processes onto the disk. So this is the idea of the phantom operating system. To put it really simply, it's a virtual machine, like Java virtual machine, but different, working in a huge persistent memory. Actually, there are new problems which we bring to life when we start to live in such an environment. First of all is garbage collection. Such a system is really a huge application server, different programs working in a big address space communicating. You cannot control memory, but by allocating and manually deleting it, you have to work with the garbage collector and the garbage collector have to collect garbage over the address space of say one terabyte size of disk. Is it possible? Actually, it is not that it's impossible, but it's very hard. So you can stop the world to collect garbage on this address space, and that was a stopper for me. One moment I thought that it is really impossible to do that, but I found the interesting article saying that it would be really easy to implement a garbage collector if the garbage collector is working not on an actual copy of address space, but on a separate, not changing copy for some moment. If we can just take the memory and put a second copy of it, we can collect garbage over this copy of memory, and everything that is garbage in the past is garbage in the future, so that we can free the memory based on the old state of the memory. For the Phantom operating system, it is a basic idea to make the copies of address space, so it is possible to write a garbage collector which is working on the snapshot of the memory. Such a garbage collector would be quite slow, so that possibly we need a second one. And the basic idea at this point is to have two garbage collectors, one of them is working slow and collects all of the garbage looking into the earlier state of the memory, and one of them is fast but not ideal. It is based on the reference count, so we cannot collect some kinds of the object structures such as object loops, but it is okay because the basic task of this collector is to collect fast allocated and fast unused objects such as automatic variables, stack frames like this. Another big problem is the blocking C-scales. In traditional Unix, the application just calls the kernel, for example, asking it to read from the keyboard. Infantomet is next to impossible because just the user space is persistent. Kernel is not persistent. Kernel is reboots and restarts from scratch as any other usual kernel. So if your system call came into the kernel code, you cannot restore the state of the user space completely. You just don't know what's going on inside of the kernel. It was a next big blocker for me. I don't have time to describe all the attempts or the ideas to pass through this problem, but the final idea was quite simple. All the blocking system calls are restartable and they made more or less, not more or less, just atomic to the user space. User space calls kernel. If the call status saved, then kernel does something to execute this call. And if kernel finished, then system call is finished and for the next snapshot it is finished. If something went wrong during the system call like we just turned off the computer abruptly, the system call for the snapshot is just not started. All the state that we need to restart system call is intact and for the virtual machine thread which restarts on the necrostat of the operating system, it just starts in the state when it's just going to implement to start the system call. One of the huge problems for such kind of operating system is that it is very different from everything we have. So thinking about how to bring a user code to this system is one of the main things to think about. For me, I believe one of the best ideas is to build a converter from the Java virtual machine class files to the Phantom class files. I can describe why the Phantom virtual machine is not, why I cannot just use, for example, actual Java virtual machine, but I have no time. So I believe that bringing the Java into the Phantom is one of the best ideas because Java brings a lot of different languages which are possibly combined to Java. But direct compilation of the languages into the Phantom bytecode is a task too. Up to this year, I was sure that it is impossible to run C programs on such an environment, but now I think that it is really possible to compile C code into the managed environment. There are a lot of problems, but I think it's really possible. One more idea is that there is a very special processor made in Russia, which is called Elbrus, which contains in hardware the layer of protection which is more or less similar to the protection level of the Java virtual machines. This is a processor which forbids you to convert integers to pointers. And on such kind of processors, it is possible to run C code on Phantom operating system in a persistent environment. But frankly, we didn't even try yet. Not a lot of resources to do that. Well, I'll try to show you this overview of the structure of the operating system. The white place on the top is the persistent memory, which is a place for the user code to live in. User code is object-oriented by design, but functional code can run as well. There is a separate version of the virtual machine for functional paradigm. This is the kernel. This is the lowest level of the kernel, which is made to be portable. So this is hardware-independent. This is more or less hardware-dependent. It is mostly made for the Intel hardware, but there was an attempt to port it into the ARM environment. It was a successful attempt, but for now it is not continued. Again, there is not a lot of resources. It's time for questions, I suppose. So I'm sorry. It's obvious that I need more time. But anyway, I have to stop, and if you have questions, please. Thank you. Because you have a single address space, everything needs to be mapped into that single address space. Of course. 64-bit address space is more or less okay. Actually, when I started to think about this, I just cannot dream about this 64-bit address space. Now it's usual. I believe that for some 10 years we will have a comparison with 128-bit address space, which is enough for anything. I hope so. At this moment, I believe that it is okay for one simple reason. The disk's actual real persistent memory is smaller than other space. And you can map any size of the disk into the 64-bit address space. Maybe, okay, but we'll wait for even bigger bus. Any questions? The question is that the newer computers will have non-wattel RAM. Am I right? Yes. Actually, I even have this question in my presentation. It is not true that if the RAM state is saved, then the kernel is automatically persistent. It is not true. Anyway, for Phantom, it just helps it to work simpler, but still you need a kind of kernel which can synchronize the saved state with the changed world. The world is changing anyway. For example, just hardware. When you restart, the memory is the same, but hardware is not the same. You still need a layer which synchronizes the state of the operating system to the state of the world. Not yet. What is the question? Can we just restart from one of the earlier states? Yes, of course, we can. We can save a lot of the snapshots and the snapshots are incremental so that they don't lose a lot of disk space. This is true. This is an automatic backup system. You can return back in time, but you cannot, for example, do a backwards execution. It is not the idea of this system. One bigger problem is that you cannot go back in time for just one application, only the OS system completely. What was the question? Yes, Elbrus. The short name is E2K. The long name is Elbrus Mountain. But it is not dependent on this. It can work on any kind of the architecture. Any more questions? Well, that's the question for another hour of discussion. The question was how do we handle the situation when the hardware changes its state in some unhandled ways? For example, if the device just took down some device from the computer and reset the priority system. To say it simply, some code will get an exception on the next attempt to access this device. Well, I believe it's all. Thank you very much.