Release 0.8.2 NEWS With 171 commits since 0.8.1, this release brings improvements to machine's core code, and some long overdue fixes. The changes in this utterly uninteresting release are mostly internal and will not (*should* not) affect user code much. EXTRACTED VIRTUAL PROCESS SCHEDULER OUT OF CPU Virtual process scheduler was extracted out of the CPU code. This means that the CPU is now only the source of static information about running program - what modules are loaded, where a function begins, what methods a class responds to, etc. It also holds the queue of FFI call requests (it has not changed since the last release). The *dynamic*, process-related information that are prone to change during lifetime of a program (e.g. frames on call stack of process, exceptions mid-flight, messeges in transfer) are now handled by "virtual process scheduler", which is a special class concerned only with managing VM processes. For now, the VM spawns only one VPS (virtual process scheduler) but in future releases it will be changed, and machine will spawn a number of VPSs - each in its own host thread. Introduction of multiple active VPSs will mark the move from just concurrency, to true parallelism of virtual processes inside the machine (i.e. they will not just run one-after-another round-robin style, but some of them might actually be running at *the same* time, only under different scheduler). FEATURE OF THE DAY: std::unique_ptr<> Machine now employs `std::unique_ptr<>` in some places in code to manage lifetime of dynamically allocated objects. The `std::unique_ptr<>` is now heavily used only in the `VirtualProcessScheduler` code to manage stack frames, exceptions, and global and static register sets, but in later releases it will gradualy replace naked pointers in other parts of the VM. LESS CRASHING, MORE STACK TRACES In previous releaes, when one virtual process crashed, and the crash was not handled by the watchdog process, it brought down the whole VM, and produced a stack trace. This behaviour is now altered: when a process crashes and there is no watchdog to catch the escaped exception the VM will print a stack trace for the crashed process but will continue running. This change is intended to enhance reliability, errors will always happend, they just should be isolated from the "healthy" parts of the system and serviced, instead of bringing the whole system down with them. What if the `main/` function crashes? If there is a watchdog process to handle the failure, the exception will be serviced and the VM will continue execution, to finish with exit code 0. If there is no watchdog process, machine will continue running and when all other processes finally terminate it will close with exit code 1. WATCHDOG PROCESS SPAWNED PER-VPS, NOT PER VM Each VPS manages its own watchdog; thus, virtual-process-crashing errors are localised to the next nearest point after the process, instead of being propagated further (to the CPU) and clogging up the metaphorical pipes. Currently, there is only one active VPS so this move does not change much, but this will pay off when machine starts spawning multiple schedulers. FUTURE According to release schedule, next release should introduce multiple FFI schedulers. This will provide speed improvements due to greater parallelism on machines with more cores to utilise (as each scheduler will run in parallel on its own thread). Machines with one and two cores will not notice any change; and there are no plans to "overschedule", i.e. to spawn more threads than there are real cores available to utilise (if the hardware provides only two cores, only one FFI scheduler will be spawned).