Just kidding, it’s doable, and here’s a recipe

Previously we found out that our industry has no language capable of handling Grid memory. No language provides enough safety and resilience. No language guarantees from memory leaks, data races and garbage collector pauses. It’s a pity, but it is not a showstopper. We can create this language ourselves. We can create these memory management, object lifetimes handling and multi-threading techniques ourselves.

It took decades, but this language was created.
Meet the Argentum programming language.

Full disclosure: Argentum programming language was intentionally designed as a foundation for the SilverDOM project (though it can be used as a general purpose stand-alone language as well).

• It’s 100% safe – no unsafe mode, no unchecked operations, it guarantees total type-memory-null-index-const-safety. No workarounds. No shortcuts. When applied to usual environments, this safety might look too extreme, but for SilverDOM – it is vital.
• It’s resilient – no exceptions, no panic, no UB. All operations that could go wrong return optional types and there is no way to access inner value wrapped in these optionals without checking for optional-none. Thus no operation could ever left unchecked.
• It is 100% protected from memory leaks. Other languages don’t see memory leaks as a big deal. GC-languages are ok with eventual garbage reclamation, Rust and Swift are ok with manual checks against cycles. In contrast Argentum’s measures against leaks might look too harsh but not in the world of Grid memory.
• It has non-blocking non-racing multithreading. It is 100% free from data-races. As for non-blocking, Argentum guarantees that no cross-thread operation can lead to blocking. But no language, library or framework can guarantee that subroutine that gained exclusive access to an object can eventually terminate and release that object. It is a well-known halting problem. So this problem should be addressed externally and separately.

At the same time the current version of Argentum programming language is far from perfect:

• It has two minor issues
• And it needs some minor adaptations to be usable in the SilverDOM project.

Issues

Argentum issues rooted in its MVP-demo status:

• it is not yet protected from stack overflows
• it cannot unwind stacks at any random point to address the halting problem.

These issues don’t block Demo/MVP iterations of SilverDOM, and they will be addressed before SilverDOM leaves MVP state.

Adaptations

1. Argentum produces OS executables while SilverDOM needs direct code segments placed inside the address ranges allocated inside the Grid memory. It is not a show stopper for a demo. As explained here: demo iteration of Grid memory we can compile code into a DLL and load it dynamically.
2. Argentum uses C-allocator from ag-runtime library. So ag_alloc/ag_free should be redefined to support some custom allocator from a range of predefined mmapped Grid memory.
3. Certain data types contain direct addresses of function entry points: Function, Delegates, Object Headers – so they should be replaced with indexes in tables residing in the code segment (DLL) – to make the persistent heap contents survive the rebuilds of application code that changes these entry points (only for the first demo phase).
4. Argentum Compiler assigns random IDs to interfaces on each invocation. So it should be provided with an in-out storage that saves the information on the existing/previous interface ids, as well as fn indexes, data layouts etc.

With these 4 tweaks Argentum will be capable to play as the 1st demo iteration of the SilverDOM platform.

Next iterations will build executable code directly inside the Grid memory (with orc::LLJIT) which would render unneeded the #3 and #4 adaptations.

At the same time using Argentum for the next iterations of SilverDOM requires to introduce binary serialization, portable execution module format (binary-serialized AST) which will diverge SilverDOM version of Argentum language from general purpose Argentum producing OS executables. But this is a theme for the distant future.

The next steps are

• make a driver app that
  • provides SDL, Scia and Curl bindings
  • mmaps a file with grid memory image at the fixed address,
  • builds application code from AG-modules info a DLL
  • loads this DLL and links it to the Skia and Curl and mmapped Grid memory range.
  • initiates SDL app lifecycle that feeds Grid objects with system event stream.
• extend driver app to support apps rebuild
• extend Argentum to support binary serialization
  • which makes it possible to exchange objects between SilverDOM nodes
  • and replaces the text AG application modules with binary-serialized AST.