Phantom – general description

Phantom – general description

Phantom is a very simple system. From the programmer's point of view Phantom is just a big graph of objects, and these objects never die. OS ensures that all the memory contents are sound and safe, even if power's going down. It is not guaranteed that the very last state of memory is saved (though it can be achieved), but it IS guaranteed that saved memory snap is consistent – all the objects are snapped at the same 'personal' timescale moment. Physically, of course, snapshot is being done quite slowly, to not to disturb user with high disk IO activity.

This snapshots machinery is not like, say, Windows Hibernate, which is saving virtual memory contents into the files. No. Phantom snapshots are internal and integral ability of the virual memory subsystem itself. It is more like not deleting and reusing later the paging data itself. In fact, all the Phantom disk strusture is big paging partition, organized as a set of generations plus some common (unchanging) part. So Phantom's snapshots machinery is very efficient due to its integration with usual paging processes.

Phantom kernel is really small and contains, mostly, paging/snapping subsystem and virtual machine interpreter (and, in near future JIT compiler too). Drivers can be implemented at kernel or application level, except for the disk drivers, which have to be in kernel so that paging will work: it is hard to work without paging for the OS which ahs nothing but paging. :)

Above the kernel the system and application parts are the same techincally and are not divided – everything is classes and objects, and all the OS services are just sets of object frameworks. Most of them user will be able to surpass or substitute with own ones (that's security subject, of course).

As everything is persistent in Phantom, it has no need in files and file system. But to present familiar user environment Phantom has directory objects, which may look as folders. They will, though, contain no files, but references to the objects. It is supposed that objects, available from those directories will be some 'high level' ones, for example, they can be forced to implement some 'application' interface (have methods such as openDocument and printDocument, or something like that), but techincally those objects are no different from, for example, ineger or string value object.

Object model

For the programmer phatom is a big virual machine. Here we will come shortly through phantom VM basics.

Objects, types
Above the kernel everything is an object. (In fact, most kernel's dynamic structures are objects as well.) Type (class) is object that is able to create objects. Class class is a root thing used to create classes.

Built in, atomic types
At this moment phantom VM is able to process objects of some predefined classes – integer, string, code, interface, class. All of them look like usual classes/objects, no special treatment from outside is needed or possible. But internally they are special and processed by kernel code directly.

To be more effective VM is able to process integers separately, in a more effective way. Such integers are specific only during processing and stored as usual objects too.

Type checks
Phantom is a dynamically typed engine. Any object’s type can be checked at runtime. Static type checks are done where type information is available, but in general it is possible to ignore types completely at compile or run time.

Exceptions
Any class can identify an exception (no special interface implementation is required, for example, for object to be thrown). Any object can be thrown, and catcher will catch it if object belongs to the type that catcher is looking for.

Calls, returns
Any number of arguments is passed, one or nothing is returned. Null object will be received if caller expects return value and called code did not return anything. (This is assumed to be impossible in a correct Phantom language program, but is possible technically.) If called code does not return some object explicitly, it is possible that some junk value will be returned. Static type checks are supposed to prevent this, but you can overcome.

Memory

Phantom objects are dynamically (heap) allocated only. No automatic (stack) objects exist. No static (classless) objects exist, but programmer can store 'global' data in the application's root class.

All the memory is processed with garbage collector. I must mention that EVERYTHING in Phantom is subject of garbage collection. Application as a whole will be killed if no object references it (practically it means that no data object for this app exist and no system directory, such as “all apps list” points to it). On the other side, it is impossible to delete an application, for which you have data objects. (Well, it is possible with the clever classes structure, but lets skip it for now.)

Of course, kernel is not accessible from applications address space, but in terms of Intel x86 CR3 register Phantom has only one address space and is completely free of context switches. It means that, for example, network IO or IPC are 'free' in Phantom in terms of context switching overhead.

One can suspect that Phantom does not protect applications one from other, but this is not true. Phantom virtual machine has no ability to access any object's data from any other object (only method calls) and it has no way of converting integer (or anything) to object reference. So you can not 'scan' memory and even can not call methods of objects you have no reference to. And you can not 'create' this reference. Only receive from other object.

Kernel access

The only possible way to communicate with kernel is via objects of some special classes. One has to have a reference to such an object to be able to work with it. Generally most of them are created on the creation of the OS instance and carefully passed between system classes without giving out to “userland”. Usually direct kernel interfaces are of no use to application code and accessed only through the OS frameworks. For example, kernel interface has to be used to allocate and access io port, but this is of use for a device driver code only and usual application code shall not be able to work with io port directly. Though, it is possible techincally – availability of such interfaces to user code is question of access control only.

It has to be mentioned, that kernel interfaces are special in terms of system reboot. All the objects feel no reboot as they will be the same after reboot, and the same threads will continue work from the last snapped position in code. Not exactly so with kernel objects, at least those used to reach out.

These objects (such ones used to access devices) will be 'dead' after reboot, and that is on purpose. Each device driver must, when system rebooted, reinitialise its device and attempt to pretend there was no reboot at all. For example, video screen driver on reboot shall reinitialise its video hardware and redisplay last known picture on it. After that driver can continue working as if no reboot hapenned. Nearly the same is with mouse and keyboard. Some worse situation is in networking field, for example. If system was stopped for long all the TCP connections are, unfortunately, timed out on the far sides. So network driver must report failure to its 'customers' – at least to TCP ones. It, possibly, would be nice for outgoing connection to reestablish it automatically, but I believe such service has to be configurable.

In any case, kernel enforces special reaction from driver by obsoleting all its hardware access points. It is a simple way to ensure that device driver author took at least some minimal care of its device after reboot, or, in case of a very lazy programmer, was disconnected from device.

To prevent possible 'holes' and inconsistencies, all the kernel access objects are obsoleted at any reboot. Any attempt to call their methods will finish with an exceptions, and any methods being in the middle of execution during reboot will be anforced to return with exception before the system will continue. It means that all threads which were snapped when they did execute kernel object method will find themselves woken up already at the beginning of the corresponding exception handler or killed, if no such naddler was found.

Hardware modification
We must be ready, as well, to the situation when OS was stopped in one hardware configuration and restarted in another. Sometimes it is easy and handled just lake some, for example, USB device connection or disconnection at runtime. Corresponding driver will just start or stop, possibly causing some userlevel reaction. But sometimes it is different. Lets look at a very simple situation: OS instance was working on 1440*900 screen, and later was restarted on 800*600 one. If resolution would get higher, it would be easy to handle: just extend the desktop. And if resolution is lower, driver have to do some magic, like move windows into the visible part of screen or something even more clever.

(todo – describe HDD conf change)