In order for SilveDOM to become reality, we need to solve a number of technical and architectural problems:
Safety
If we let the application code from different vendors to reside the same address space and let all data ever existing in the computer to live in the same space, we need to protect our DOM from bad code. Let’s be honest, in today’s world badly written application can destroy all user data easily: by recursively scanning directories and deleting all files or writing random pieces of data in random files. So the operating system doesn’t protect user data from ill-written programs. In SilverDOM data access is radically simplified. Just write random bytes at random addresses in the Grid memory and all data and code is done. This means SilverDOM should create an impenetrable perimeter in the form of high-level language protecting the code and data from any unsafe actions such as but limited to:
- unchecked typecasts for pointers
- undefined behavior
- reinterpret and bit-casts between primitive types
- skipped null checks
- access to untagged unions
- indexation in containers without bounds checks
- access to optional values without checks for opt-none
- stack overflows
- memory and time quota depletion
Unfortunately even Rust, Swift and many other languages named as safe, have unsafe mode, unchecked operations and workarounds allowing to bypass their safety features. SilverDOM language should completely exclude any unsafe operation. It shouldn’t have unsafe mode at all.
Resilience
In SilverDOM running code has no application life cycle. Our applications exist in memory indefinitely. As such we cannot unload or restart our applications on failures. This requires our SilverDOM programming language to be resilient. It should not allow to panic/exit/terminate, so each language construct should provide ways to go in case of typecast errors, null-pointer errors, indexation errors, etc. There always should be an else branch in all operations that could go wrongfully. Unfortunately, all nowadays programming languages provide easy ways to terminate, such as:
- unhandled exceptions
- null-pointer crashes
- type-cast failures
SilverDOM programming language should never crash.
Memory leaks
When all your data is located in one system-wide multi-terabyte persistent heap, the last thing you want to happen – is leaking memory. Ill-written applications can easily deplete this heap overloading the operating systems blocking operations of other applications, and this can’t be fixed by system reboot, because all heap content is persistent. That’s why the SilverDOM programming language must have totally and fully automated memory management, without the ability of manual memory allocation and reclamation. Let’s see how nowadays programming languages prevent memory leaks.
Three are three types of memory management nowadays:
- manual memory management
- garbage collected approach
- ref-counting that mostly used in Swift and Rust.
Manual memory management cannot guarantee anything – not only absence of memory leaks but also memory safety.
Ref-counting memory handling doesn’t help with memory leaks. Even Rust book says: “memory leaks are memory safe in Rust”.
Garbage Collector approach is also unable to prevent memory leaks, because of three reasons:
- in garbage collector environment object deleted from its hierarchy it’s still referenced by multiple subsystems and these references keep this unused object alive
- most garbage collectors don’t scan all memory but rather use generation based approach, which means that some objects are collected with larger intervals and some objects just slip between generations and not collected for years
- most modern garbage collectors use conservative approach, that means that if a value type in stack reminds some pointer, the object it “points” to considered alive.
Garbage collector has another issue. When it starts tracing references, at some stage it stops the world: it pauses all running threads. For SilverDOM where all threads live in the same address space, this “stop-the-world” means actual freeze of all activity. Also in the worst case scenario garbage collector traces all references and visit every object of the SilverDOM. In case of Grid memory it means that all content of SSD will be multiple times loaded into RAM creating overwhelming data traffic. Modern computers have RAM to Storage ratio is 1:64, which means that 98.5% of your heap is permanently evicted to the external storage. In the worst case, collection would take minutes and hour of freezing of all operations. So in general Garbage collectors are completely incompatible with virtual memory.
Bottom line is: unfortunately none of today’s programming languages’ approach towards memory management and preventing memory leaks is applicable to SilverDOM.
Threads, Data Races and Deadlocks
Imagine the flat address space containing all documents and all running applications simultaneously, and all applications modify all documents in multiple threads. Is it a dream or a nightmare?
How to prevent data races in this architecture? Another question: what would protect us from deadlocks, if all synchronization primitives we have are low level mutexes and conditional variables?
Our high-level SilverDOM language must be equipped with high-level thread management. It should automate all synchronizations. It should ensure that not a single mutable object could ever be accessed from two threads.
Nowadays there is no programming language that could give such guarantees: totally prevent from deadlocks and data races. Even Erlang and Go with their message passing/channels approach can create deadlocks on unresponsive or circular waiting processes/routines.
No programming language fits these requirements
Let’s be honest, the idea of flat linear persistent RAM is not new. It was attempted many times, but it failed because it has so many issues that haven’t been solved for all those years:
- Safety
- Resilience
- Memory Leaks
- Multithreading
No matter how bright this idea looks, it never provided a competitive solution in comparison to the traditional approach of RAM-AppProcesses-Heaps/SSD-Files classic.
SilverDOM is just impossible to implement at the industrial quality grade.
We do not have languages suitable for writing applications for SilverDOM.
So no hope?
