Alternate Lua virtual machine (WIP)
Go to file
2025-09-05 21:14:32 +03:00
stc Initial commit 2025-08-31 16:22:38 +03:00
dump.h Initial commit 2025-08-31 16:22:38 +03:00
lexer.c more expression types 2025-09-05 21:14:32 +03:00
lexer.h Add concurrency 2025-09-03 01:03:45 +03:00
main.c Add concurrency 2025-09-03 01:03:45 +03:00
Makefile update makefile 2025-09-05 21:13:13 +03:00
parse.c more expression types 2025-09-05 21:14:32 +03:00
parse.h Initial commit 2025-08-31 16:22:38 +03:00
README.md update readme 2025-09-05 21:13:22 +03:00
str.h Initial commit 2025-08-31 16:22:38 +03:00
table.h Add concurrency 2025-09-03 01:03:45 +03:00
value.h Initial commit 2025-08-31 16:22:38 +03:00
vm.c Add concurrency 2025-09-03 01:03:45 +03:00
vm.h Add concurrency 2025-09-03 01:03:45 +03:00

Impotent

This is an attempt to create a Lua virtual machine capable of true multithreading. Once the nctref compiler matures enough, I intend to plug it into Impotent as a JIT.

Completed features:

  1. Per-thread heap /w special heap for exited threads called the "dead heap"
  2. Naive mark & sweep GC
  3. Completely thread-safe, including lock-free implementation for tables

Impotent is still work-in-progress:

  1. Integers are 32-bit only
  2. No error handling, meaning any mistake will either crash the VM or make it silently fail
  3. The only standard library is print and it doesn't work correctly
  4. Tables cannot be resized
  5. Most operators are still missing
  6. The user API is completely different from that of PoC Lua
  7. Being lock-free, tables are not split to "array" and "hash" parts

Impotent requires C11 and an architecture with 8-byte atomic operations, but otherwise it is completely cross-platform.

Performance-wise, it's surprisingly competitive with PoC Lua, considering how quickly it was made up to the point of writing this README (~2 weeks). By far the worst bottleneck is the GC, since it requires all threads and their heaps to synchronize.

Certain Lua idioms become impossible under Impotent. For example the idiom of appending to tables (t[#t + 1] = x) isn't atomic, therefore table.insert should be used instead.