MoarVM

MoarVM provides very little directly - and that's a good thing. It is not tied to a particular way of doing inheritance, roles, mixins, method resolution, type-checking, and so forth. Instead, meta-objects written in a high level language implement the desired semantics.

What MoarVM does provide is representations: ways of using and accessing memory. Meta-objects provide a description of the kind of representation that is needed, and MoarVM does the required work to compute structures, array storage, and so forth.

MoarVM has a generational garbage collector. The young generation is managed by semi-space copying, making it cheap for objects to die young. The old generation is broken into sized buckets, with very large objects being specially handled. Since objects move over their lifetime, garbage collection is precise. When multiple threads are running, collection can run in parallel (meaning that the world is stopped, and multiple threads work on the collection job to get it done more swiftly). There is also support for finalizers.

The GC has undergone stress-testing, including doing Rakudo builds with collection runs after every object allocation and using many memory-protected past fromspaces in order to catch a wide range of possible bugs. While of course this is not a proof that no bugs remain, it does mean they've been left little room to hide.

The usual range of mathematical and string operations are on offer. Other features worth mentioning are:

• First-class code objects
• Lexical variables and closures
• Exceptions, with resumption support
• Single-shot continuations
• I/O (files, pipes, sockets), and a range of file system and process operations
• Big integers
• Taking references to native lexicals, attributes, and array elements
• Runtime loading/evaluation of code
• Bounded serialization
• Native calling, passing pointers, arrays, structs, and callbacks
• Threads, mutexes, conditional variables, semaphores and concurrent blocking queues
• Asynchronous sockets, timers, signal handlers, file system notifications, and processes

Hot code is detected and optimized. On x64, much hot code can also be JIT-compiled into machine code. The optimizer specializes code by the number and types of incoming arguments. Since de-optimization is also available, speculative optimizations can be performed. Small routines called by hot code may be inlined, and hot loops are detected and replaced with an optimized version (known as On Stack Replacement).

MoarVM includes the Unicode 15 database, and can do property lookups (such as those required in regular expression matching), character and sequence resolution by name, case change operations, comparisons using the Unicode Collation Algorithm, etc. Strings work at grapheme level. MoarVM strings are opaque, and there is no confusion between strings and bunches of bytes. It makes no sense to ask for a string's encoding; rather, a string can be turned into a bunch of bytes using an encoding.

MoarVM has no official assembly language, and at present no known unofficial assembler. Provided a compiler is written using the NQP compiler toolchain (which NQP and Rakudo are), then code can be generated by producing a MAST data structure.

MoarVM supports instrumented profiling for precise runtime and allocation profiling, and heap snapshots for memory use profiling and leak hunting.