Let us look at how Grafana k6 executes load tests. If you are coming from legacy performance tools like JMeter or Gatling, you are probably used to managing heavy JVM runtimes. You know the drill: configuring heap sizes, fighting thread limits, and watching memory usage fly through the roof. k6 does things differently by compiling a Go binary with an embedded JavaScript virtual machine. This approach is highly efficient, but it requires understanding how k6 handles JavaScript execution.
Understanding the runtime internals is vital to writing efficient test scripts. If you do not know how k6 interprets your JavaScript code, you will end up building memory-heavy scenarios that crash your load generator. Let us dive deep into the engine that powers k6 execution.
The Evolution of the JavaScript Interpreter: From Otto to Sobek
Historically, Go-native JavaScript scripting engines relied on a library called Otto. Otto was a decent proof of concept, but it had massive problems when it came to scaling load generation. It suffered from elevated memory utilization and slow execution speeds. When you are running thousands of virtual users, every millisecond and every megabyte counts. To solve this bottleneck, the k6 core engine migrated to Goja. Goja executed JavaScript loops six to seven times faster than Otto while keeping the heap footprint remarkably small.
However, Goja had its own limitations. The most critical issue was the lack of native ECMAScript Modules (ESM) support, which is standard in modern JavaScript development. The Grafana engineering team needed a way to support ESM without sacrificing performance. To solve this, they forked Goja and created Sobek. Sobek is the default, highly optimized JavaScript execution engine embedded within all modern k6 and xk6 binaries. It provides native evaluation of modern JavaScript standards directly inside the Go application.
How Sobek Executes Your Code
When you run a k6 test, the Go application spawns multiple Virtual Users (VUs). For every single VU, k6 creates an isolated Sobek virtual machine instance. This is a critical detail that many developers miss. If you have 500 VUs, you have 500 independent Sobek engines running in parallel. Each engine compiles and evaluates your test script independently.
This isolation guarantees thread safety. One VU cannot access or modify the state of another VU, which prevents race conditions. But this design has a major cost: memory duplication. Because every Sobek VM compiles its own local copy of all imported modules, importing large libraries will cause your memory footprint to swell. A simple script might require just 1MB to 5MB of RAM per VU, but importing massive external dependencies can push that footprint to tens of megabytes per VU. When scaled to thousands of concurrent users, this memory overhead can easily overwhelm your system.
Solving Memory Duplication with SharedArray
To prevent massive memory bloat when loading large datasets (such as CSV spreadsheets, lists of credentials, or complex configuration parameters), k6 introduced a unique data structure called SharedArray. SharedArray allocates memory on a read-only Go heap that is shared across all VUs. Instead of duplicating the test data 500 times for 500 virtual machines, k6 loads the data exactly once. Each Sobek VM then references the same read-only heap data without copying it into its local context.
This is a massive win for performance. If you are dealing with a 50MB user database, using a standard JavaScript array in 500 VUs would require 25GB of RAM. Using SharedArray reduces that requirement to just 50MB plus a tiny bit of pointer overhead. If you are not using SharedArray for your static test data, you are actively wasting system memory.
In our next post on k6 vs JMeter: Why Goroutine Multiplexing Crushes OS Threads, we will look at how the Go runtime schedules these Sobek virtual machines. To understand how to bundle modern npm assets for k6, read The k6 Node.js Event Loop Paradox and Webpack Bundling. If you want to configure these options in a production environment, read our guide on Enterprise k6 Scripting: Custom Telemetry, Thresholds, and SharedArray.