Download Game! Currently 74 players and visitors. Last logged in:PotionOmnipotentCelbornKandahar

Blitzer's Blog >> 71904

Back to blogs index
Posted: 31 Aug 2026 09:16 [ permalink ]
Kuulostaa erittC$in kunnianhimoiselta ja tyylikkC$C$ltC$ arkkitehtuurilta.
Kuvauksesi perusteella olet rakentamassa puhdasta datavetoista tilakonetta
(state machine), joka yhdistC$C$ Actor-mallin, LMAX Disruptor -tyyppisen
lock-free rengaspuskurin ja Event Sourcingin.
TC$mC$ sopii tC$ydellisesti kuvailemaasi bare metal mquickjs -mikrokerneliin,
jossa I/O voidaan hoitaa suoraan muistimapC$ttyinC$ (memory-mapped)
laitteistokeskeytyksinC$ tai rinnakkaisten ytimien vC$lisenC$ kommunikaationa.
TC$ssC$ on ehdotus siitC$, miten tC$llaisen moottorin arkkitehtuuri kannattaa
jaksottaa JS-ekosysteemissC$:
Arkkitehtuurin kulmakivet
1. Lock-free Mailboxit (Ring Buffers)
Koska kaikki kommunikaatio kulkee rajattoman mC$C$rC$n IN- ja OUT-vC$yliC$
pitkin, ja jC$rjestelmC$n tulee olla lukoton (lock-free), oikea tietorakenne
vC$ylille on Single-Producer-Single-Consumer (SPSC) Ring Buffer.
 * Toteutus: Luodaan SharedArrayBuffer (SAB), jonka alkuun varataan tilaa
head- ja tail-osoittimille.
 * Atomics: Lukottomuus saavutetaan Atomics.load() ja Atomics.store()
-operaatioilla. Head- ja tail-indeksejC$ pC$ivitetC$C$n atomisesti, jolloin
lukija (core) tietC$C$ milloin uutta dataa on saatavilla (head !== tail), ja
kirjoittaja tietC$C$ milloin puskurissa on tilaa.
 * Viestien rakenne: Vaikka kC$sittelet JSON-paketteja, ne on koodattava UTF-8
-tavujonoksi SAB:iin (esim. TextEncoder / TextDecoder avulla). Puskurin
solmussa on viestin pituus (header) ja itse payload (JSON).
2. Jaettu muisti ja olioiden tallennus
TC$ssC$ piilee JS-toteutuksen isoin tekninen valinta. Jos "kaikki data on
jaetussa muistissa", et voi sC$ilyttC$C$ varsinaista tietokantadataa
normaaleina V8/QuickJS-olioina (heapissa), koska niitC$ ei voi suoraan jakaa
toisille prosesseille (esim. Web Workereille) ilman hidasta rakenteellista
kopiointia (Structured Clone).
 * Slab Allocator / Custom Memory Manager: Ydinpalvelun tulee toimia
muistinhallintana. SAB toimii suurena tavutaulukkona (Uint8Array / DataView),
jonne core pilkkoo dynaamisesti tilaa saapuville JSON-olioille.
 * Olioviittaukset (Pointers): API-kerros tai muut prosessit eivC$t saa
suoraan muistiosoitteita, vaan "kahvoja" (Handle / ID), joilla core hakee
datan oikeasta offsetista, kun lukupyyntC6 tulee IN-vC$ylC$C$n.
3. Synkronointi "mihin tahansa streamiin"
Koska tietokannassa ei ole API:a, vaan ainoastaan sisC$C$n ja ulos meneviC$
viestejC$, jC$rjestelmC$ on luonnostaan Event Sourced.
 * Write-Ahead Log (WAL) suoraan ulostulona: Jokainen IN-vC$ylC$C$n tullut
mutaatiokomento (INSERT/UPDATE/DELETE) emittoituu onnistuneen kC$sittelyn
jC$lkeen OUT-vC$ylC$C$n eventtinC$.
 * Stream-agnostisuus: Jos haluat tallentaa datan levylle, yksi rinnakkaisista
tyC6ntekijC6istC$ (worker) kuuntelee OUT-vC$ylC$C$ ja kirjoittaa eventit
ZFS-pooliin tai verkkosocketiin. Jos haluat replikoida toiselle koneelle,
toinen worker puskee saman streamin Tailscale-verkkoon WebSocketin yli. Core
ei tiedC$ tC$stC$ mitC$C$n.
 * Snapshottien helppous: Koska koko tietokannan tila makaa yhdessC$ (tai
useammassa) suuressa SharedArrayBufferissa, kokonaisen snapshotin streamaus
verkon tai tallennusmedian yli on vain puhdas binC$C$ridumppi nykyisestC$
muistialueesta.
4. YmpC$ristC6agnostinen suoritus
TC$mC$ arkkitehtuuri eristC$C$ tietokannan tC$ydellisesti ympC$ristC6stC$.
 * Selaimessa: PC$C$sC$ie luo SAB:t, renderC6i UI:n (esim. Mesh OS -tyyppinen
ikkunointi) ja siirtC$C$ viestejC$ workerille.
 * Nodessa: worker_threads lukee ja kirjoittaa SAB-mailbokseihin, kun
pC$C$sC$ie hoitaa verkko-I/O:n (esim. FastAPIn tyyppinen reititin).
 * Bare metal (mquickjs): boot.s alustaa muistisivut, hyppC$C$ suoraan
QuickJS-looppiin, ja Coren IN/OUT vC$ylC$t voivat olla suoraan mapattuna
laitteiston fyysisiin muistiosoitteisiin tai jaettuun muistiin muiden
mikropalveluiden kanssa.
Kriittinen pullonkaula: JSON
Ainoa potentiaalinen suorituskykyongelma tC$ssC$ on JSON. Jos tavoittelet
satojen tuhansien rivien sekuntivauhtia, jatkuva JSON.parse() ja
JSON.stringify() ydinsilmukassa tulee olemaan CPU:n suurin yksittC$inen
kuluerC$. Koska core lukee vain tavuja SAB:sta, Binary JSON (BSON),
MessagePack tai jopa staattinen sarakepohjainen (columnar) binC$C$riformaatti
mailbokseissa nostaisi suorituskyvyn moninkertaiseksi, vaikka API-kerros
tarjoaisi ulospC$in puhdasta JSONia.