Stress / 06

Memory pressure.

Allocates 50 MB chunks until the JS heap pushes back. Reports total MB allocated without stall.

Notes

Per-tab heap limits: Chrome ~4 GB, Firefox ~2 GB, iOS Safari ~1.5 GB, Android Chrome varies. This won't hit your full RAM ceiling — it reveals the tab limit.

How it works

On each iteration we new Uint8Array(50 * 1024 * 1024) and walk every 4 KB to force the OS to back the pages with real RAM. If the allocator throws, we stop and report the previous total.

We cap at 32 iterations (1.6 GB) so the test always terminates. After we're done, the references are cleared and the GC reclaims everything in 1-3 seconds.

Frequently asked

Why doesn't this report my full RAM?

Browsers cap per-tab JS heap to protect the rest of the system. Chrome / Edge on 64-bit desktop allows ~4 GB. Firefox ~2 GB. iOS Safari ~1.5 GB. Android Chrome varies with device memory (~50% of total RAM as a soft ceiling). The number here is the tab's effective limit, not your total RAM.

What does this test actually allocate?

Uint8Array chunks of 50 MB each, up to 32 chunks (1.6 GB total cap). After each successful allocation we walk every 4 KB page once to force the OS to actually back the memory — without that, the OS lazily commits only what's touched.

Is it safe to run?

Yes — we cap at 1.6 GB and release everything immediately after. Worst case is your browser becomes briefly sluggish; the GC will reclaim the buffers within a couple seconds.

Why does it stop before the documented limit?

Allocator fragmentation. Even if the engine ceiling is 4 GB, contiguous Uint8Array allocations can fail earlier if heap fragmentation prevents a 50 MB contiguous block. That's actually useful information — a fragmented heap behaves like a smaller one in practice.

Does this measure real RAM speed?

No — for that, use the storage IOPS test or the CPU benchmark (which is bandwidth-bound when threads share L3). This test measures whether the allocation can be made and the pages touched, not throughput.