Humainary Substrates 3.15.3 · Showcase benchmark

A million circuits, 8.5 billion deliveries a second

Google Compute Engine c4d-standard-32 · 1 November 2026

One Java process held one million circuits, each with its own virtual thread, and carried 8.4 to 8.7 billion deliveries a second through them. It held that rate for 20 minutes without slowing.

8.4–8.7 G

Deliveries a second

20 min

Held without slowing

3.7–3.8 ns

Processor time per delivery

< 1%

Variation, round to round

≈ 2 KB

Heap per circuit

The four runs

25.5 trillion deliveries in 50 minutes of measurement.

Figure	Run 1	Run 2	Run 3	Run 4
Length	5 minutes	5 minutes	20 minutes	20 minutes
Deliveries per second	8.69 billion	8.51 billion	8.53 billion	8.42 billion
Deliveries	2.62 trillion	2.56 trillion	10.24 trillion	10.11 trillion
Processor time per delivery	3.66 ns	3.75 ns	3.71 ns	3.79 ns
Handoffs between circuits per second	271,600	266,100	266,600	263,200
Round-to-round variation (cv)	0.6%	0.6%	0.7%	0.6%
Processors busy	99%	100%	99%	100%
Garbage collections	2	2	4	5
Heap held per circuit	2,079 bytes	2,075 bytes	2,049 bytes	2,039 bytes
Time to build 1,000,000 circuits	0.50 s	0.49 s	0.50 s	0.71 s

The four runs used three VMs of the same type. Runs 1 and 2 ran one after the other on one VM, and run 3 on a second. Run 4 ran on a third, in a fresh JVM, straight after an observed 20-minute run that this report leaves out.

What Substrates is

A Java runtime for event-driven data flow.

Its central object is the circuit: a processing engine with one worker thread, which runs every event sent to it in order. Code emits values into a circuit through pipes, and the circuit hands each value to a receptor, the callback that processes it.

Each circuit’s worker is a Java virtual thread. A circuit with nothing to do parks its thread and costs no processor time. That makes it practical to hold very large numbers of circuits in one process, for example one per simulated entity in a model.

How much work can a single JVM push through a million of them?

What the test does

A relay race run by the circuits themselves.

Main thread
seeds and verifies

Circuit 1
holds the token

Circuit 2

31,247 more

Circuit 31,250

seed

hand off

32,000 deliveries to itself

× 32 chains, one per processor

the last circuit signals the main thread

One chain of 31,250 circuits. Every circuit in it bursts and hands off in turn; 32 chains run at once, so 32 tokens are moving at any moment and the rest of the million are parked.

Build. The program creates 1,000,000 circuits and splits them into 32 chains of 31,250, one chain per processor.
Seed. Each round, the main thread drops one token into the first circuit of each chain. That gives 32 tokens moving at once.
Burst. A circuit holding the token delivers it to itself 32,000 times in a row. Each of these is a full delivery through the circuit’s queue to its receptor.
Hand off. After its burst, the circuit passes the token to the next circuit in its chain. This crosses threads: the next circuit’s virtual thread is woken and takes over.
Finish. The last circuit in each chain signals the main thread. When all 32 have signalled, the round is over.
Verify. The main thread checks that every circuit made exactly the number of deliveries it should have. A wrong count stops the run with an error. A lost token would instead stall its chain, and the run would wait for it indefinitely.

Per round
Circuits visited	1,000,000
Deliveries	32,000,000,000
Handoffs between circuits	999,968
Round length here	about 3.7 s

The program runs two warmup rounds, which are reported but not counted. The first starts every circuit’s worker and lets the JIT compiler optimise the code. The second absorbs the extra allocation that follows the first round’s garbage collections. Measured rounds then repeat until the run’s length has passed: five minutes by default, twenty for runs 3 and 4.

The workload is driven entirely by Substrates through its public API. The main thread does no delivery work: it seeds, waits, verifies and reports. The receptor does nothing but count and pass the token on, so the figures measure the runtime’s own cost of moving events.

Each run is a fresh JVM. Run 2 followed run 1 on the same machine; they did not overlap. Run 4 followed an observed 20-minute run on its machine.

Environment

Three VMs of one type, each built for the test and deleted after.

Machine

Cloud	Google Compute Engine, Spot VM
Machine type	c4d-standard-32
Zone	us-west4-a
Processor	AMD EPYC 9B45
Processors	32 vCPUs: 16 physical cores, 2 hardware threads each
Sockets, NUMA	1 socket, 1 NUMA node
Memory	122 GiB
Hypervisor	KVM
Price at run time	about $0.27 an hour (Spot)

Software

Operating system	Ubuntu 24.04.5 LTS, kernel 7.0.0-1014-gcp
Java	OpenJDK 27.0.1.0.3 (general availability build, checksum-pinned)
Garbage collector	G1
Heap	8,325 MiB, fixed and pre-touched (512 MiB + 8 KiB per circuit)
JVM flags	`-server -Xms8325m -Xmx8325m -XX:+AlwaysPreTouch -XX:+UseG1GC`
Substrates API	3.15.3
Provider	Humainary alpha provider 3.15.3 (`humainary-substrates-spi-alpha`)
Benchmark	Perfkit 3.15.3, `io.humainary.perfkit.showcase.Showcase`
Source	commit `4584fc91`; run 4’s checkout also had uncommitted edits to `perfkit/jmh-showcase.sh` and `perfkit/README.md`

Each VM was created for this test, built the source on the machine, ran its runs, and was deleted. No other workload ran on it. Package updates were disabled for the duration. Run 4’s VM first ran an observed 20-minute run, which this report leaves out. Run 4 began 21 minutes after that VM booted; runs 1 and 3 began a minute after theirs.

The benchmark jar built on each of the three VMs was byte-identical (SHA-256 85f172efb149b9f4381e1063d566ab81cb1413456ceea6ba3faaf0a70ff31ab3), and every run was launched with the JVM flags above. Run 4’s uncommitted edits added two settings to the runner’s --observe option, and run 4 used neither. They changed neither the code it measured nor how it was started.

Results · Steady for twenty minutes

Throughput held flat across every run.

The last ten rounds were no slower than the first ten in any of them. The few slow rounds were isolated single rounds, each within 5% of its run’s median.

Run 1 · 82 roundsRun 2 · 80 roundsDeliveries per second, billions · axis starts at 8.0

8.8 8.6 8.4 8.2 8.0 Round 1 20 40 60 82 Run 1 Run 2 ← run 2, round 8: 8.21, the slowest of both runs

Run	Rounds	Slowest round	Median round	Fastest round	First 10 rounds	Last 10 rounds
1	82	8.39 G/s	8.71 G/s	8.74 G/s	8.67 G/s	8.72 G/s
2	80	8.21 G/s	8.53 G/s	8.54 G/s	8.50 G/s	8.54 G/s
3	320	8.31 G/s	8.51 G/s	8.64 G/s	8.52 G/s	8.55 G/s
4	316	8.05 G/s	8.43 G/s	8.50 G/s	8.39 G/s	8.46 G/s

The 20-minute runs, in blocks of 60 rounds

About 3¾ minutes a block, in deliveries per second.

Rounds	1 – 60	61 – 120	121 – 180	181 – 240	241 – 300
Run 3	8.51 G	8.49 G	8.59 G	8.56 G	8.50 G
Run 4	8.40 G	8.41 G	8.44 G	8.44 G	8.43 G

Processor time per delivery stayed at 3.70 ns in every block of run 3 and 3.80 ns in every block of run 4.

Results · Run to run

The four runs span 3%, from 8.42 to 8.69 billion a second.

That is larger than the variation inside any run, so a single run’s figure should be read as within a few percent of what another fresh JVM, or another VM of the same type, would give. Runs 1 and 2, on the same VM, differ by 2%.

Results · Memory

The workload itself allocates nothing.

In about nine rounds in ten, a circuit visit allocated 24 bytes on average: the one small task object the JDK creates each time it wakes a virtual thread.

Round without a collectionRound with a collectionBytes allocated per circuit visit

Run 1 480 240 0 14 31 82

Run 2 480 240 0 14 31 80

The floor is 24 bytes a visit. Rounds 14 and 31 allocated about 430 bytes a visit in all four runs with no collection counted; the cause is not established.

Each run had two to five garbage collections. A round during or just after a collection allocates more: about 300 to 440 bytes a visit. After a collection the JDK cannot reuse a parked virtual thread’s saved stack, so each circuit allocates a new one the next time it goes idle.

This is the JDK’s behaviour, and it is why the heap is sized at 8 KiB per circuit: room enough that these collections stay rare.

After the rounds, each circuit held 2,039 to 2,079 bytes of heap. A million circuits therefore fit in about 2 GB.

About half of that is particular to the first population a JVM builds, as the next section shows.

Results · Building and dropping the population, ten times

Nothing leaks.

A separate test built a million circuits, ran three busy rounds through them, closed every circuit and dropped every reference, then did it again, ten times in one JVM. After each close it forced a full collection and read the heap.

Heap while running

GB, per cycle

2.081.131.04, cycles 3 – 10

Heap left after closing

MB, per cycle

31.027.0, cycles 2 – 10

Cycle	Build time	Deliveries/s	Heap while running	Heap left after closing
1	0.48 s	2.61 G	2.08 GB	31.0 MB
2	0.32 s	3.19 G	1.13 GB	27.0 MB
3 – 10	0.17 – 0.34 s	3.10 – 3.23 G	1.04 GB	27.0 MB, every cycle

Nothing leaks

From the second cycle to the tenth, the heap left after closing never grew: it held at 27,016,432 bytes for four cycles, then fell by 280 bytes. Once the circuits closed, no virtual thread, saved stack or provider object of theirs remained.

What stays is the JDK’s, and it does not grow

The 25 MB left above the starting heap is sized by the largest population the JVM has held: the table the JDK keeps of every thread (8.4 MB), the virtual-thread scheduler’s queues (4.2 MB) and a filler object of the garbage collector (4.2 MB).

A steady population costs about 1 KB a circuit

The first population holds twice that, and the difference is almost all saved stacks. With the JDK’s default settings, the first population kept 1.78 saved stacks per circuit, averaging 715 bytes. With thread tracking off (-Djdk.trackAllThreads=false), it kept two per circuit, averaging 659 bytes, and a population built later kept one of 305 bytes. Every showcase run is a fresh JVM, which is why it reports about 2 KB.

This test ran on an Apple M4 laptop (10 cores, 4 performance and 6 efficiency, 16 GB, macOS 27.2, Java 27+35) with 10 tokens and the showcase’s heap and collector settings. Its throughput is the laptop’s and is not comparable with the Compute Engine figures. The probe’s program, console log, full heap histograms and run notes are in the memory-probe/ folder beside this report.

Compared with earlier runs

Context, not a like-for-like comparison.

All on Compute Engine with the same processor, 1,000,000 circuits and a token per processor. The earlier runs used earlier code and, before 31 October’s change, a smaller heap.

Before 3.15.2, 4 KiB heap per circuit3.15.3, 8 KiBDeliveries per second, billions · bar to the lowest run, mark across the range

c4d-standard-1631 Oct · before 3.15.2 · 5 min

4.00 G

c4d-standard-32, 4 runs31 Oct · before 3.15.2 · 5 min

8.23 – 8.41 G

c4d-standard-32, 2 runs1 Nov · 3.15.3 · 5 min

8.51 – 8.69 G

c4d-standard-32, 2 runs1 Nov · 3.15.3 · 20 min

8.42 – 8.53 G

Date	Machine	Code	Heap per circuit	Minutes	Deliveries/s	cv	Collections
31 Oct 2026	c4d-standard-16	before 3.15.2 (`6593d51f`)	4 KiB	5	4.00 G	2.7%	21
31 Oct 2026	c4d-standard-32, 4 runs	before 3.15.2	4 KiB	5	8.23 – 8.41 G	1.5 – 2.6%	7 – 47
1 Nov 2026	c4d-standard-32, 2 runs	3.15.3 (`4584fc91`)	8 KiB	5	8.51 – 8.69 G	0.6%	2
1 Nov 2026	c4d-standard-32, 2 runs	3.15.3 (`4584fc91`)	8 KiB	20	8.42 – 8.53 G	0.6 – 0.7%	4 – 5

Two of the four earlier c4d-standard-32 runs were observed: they recorded collections and host samples. Every 3.15.3 figure in this report comes from a run that was not. The time to build a million circuits varied from 0.49 s to 0.80 s across these VMs, so a single build time is not a figure to compare.

How to read the figures

What each column measures, and what a healthy run shows.

Column	Meaning	A healthy run shows
Deliveries per second	Values passed through a circuit’s queue to its receptor, across all circuits	Flat across rounds
Handoffs per second	Tokens passed from one circuit to another, each waking a parked virtual thread	Flat across rounds
Busy	Share of all processors’ time the process used	Close to 100%
ns cpu per delivery	Processor time summed over all processors, divided by deliveries	Low and flat
Bytes per visit	Heap allocated per circuit visit; a round visits every circuit once	24 bytes between collections
Collections	Garbage collections during the round	Rare
cv	Standard deviation of the measured rounds’ rates, divided by their mean	Under about 3%
Heap held per circuit	Heap in use after the rounds, after a full collection, divided by the circuits	About 2 KB in a fresh JVM

Two figures that look alike measure different things

ns cpu per delivery is processor time

With 32 processors busy, the machine completes a delivery about every 0.12 ns of wall time, while each one costs 3.7 ns of some processor’s time.

Deliveries per circuit per second is about 8,600

Most circuits are parked at any moment: only 32 hold a token. The figure shows how much work a large idle population can absorb when it is woken, not how busy each circuit is.

What this does not show

Four limits on what these figures can claim.

One process

All circuits are in one JVM on one machine. Substrates does not yet stream between processes, and this test does not measure distribution.

A runtime cost, not an application

The receptor does no work of its own. A real application adds its own processing to each delivery.

Earlier releases declined over five minutes

Runs on code from before 3.15.2, with a heap of 4 KiB per circuit, fell 3 to 5%. The 3.15.3 runs, with 8 KiB, did not. These runs cannot say whether the code or the heap made the difference.

One machine type

The figures are for a 32-vCPU AMD EPYC Spot VM. Other processors and other clouds will differ.

Reproducing the run

Perfkit builds nothing it measures.

The showcase is part of Perfkit, Humainary’s public benchmark suite (humainary-io/perfkit-java). It runs against any Substrates provider named by its Maven coordinates. These results used the Humainary alpha provider.

With JDK 27 active, and the Substrates and Serventis APIs and the provider in the local Maven repository, build the benchmark jar naming its provider, then run the showcase. From a clone of perfkit-java:

SPI_GROUP=io.humainary.substrates \
SPI_ARTIFACT=humainary-substrates-spi-alpha \
SPI_VERSION=3.15.3 \
  ./jmh.sh build                 # the benchmark jar, naming its provider
./jmh.sh showcase                # a million circuits, five minutes, a token per processor
./jmh.sh showcase --repeat 2     # two runs, one after the other
./jmh.sh showcase --minutes 20   # a twenty-minute run

Every option, column and default is described in the Perfkit README. Results go to results/<timestamp>-showcase/, with each run’s console log, a summary line, and a record of the machine, the JVM and the exact source.

These runs’ records are in perfkit/results/ of the Humainary workspace: runs 1 and 2 in 20261101T072128Z-c4d-standard-32-showcase/, run 3 in 20261101T090646Z-c4d-standard-32-showcase/ and run 4 in 20261101T110616Z-c4d-standard-32-showcase/.

Appendix · The data

Every measured round of runs 1 and 2.

Deliveries per second are in billions. Run 2 had 80 rounds and run 1 had 82, because each run counts rounds until five minutes have passed. Coral marks a round with a garbage collection. The rounds of runs 3 and 4 are in their console logs.

Round	Run 1 seconds	Run 1 deliveries/s	Run 1 bytes/visit	Run 1 collections	Run 2 seconds	Run 2 deliveries/s	Run 2 bytes/visit	Run 2 collections
1	3.690	8.67	94	0	3.771	8.49	41	0
2	3.691	8.67	24	0	3.752	8.53	24	0
3	3.675	8.71	24	0	3.748	8.54	24	0
4	3.672	8.71	24	0	3.749	8.53	24	0
5	3.678	8.70	24	0	3.747	8.54	24	0
6	3.677	8.70	24	0	3.746	8.54	24	0
7	3.675	8.71	24	0	3.747	8.54	24	0
8	3.673	8.71	24	0	3.897	8.21	24	0
9	3.814	8.39	24	0	3.750	8.53	24	0
10	3.679	8.70	24	0	3.764	8.50	24	0
11	3.675	8.71	24	0	3.749	8.54	24	0
12	3.689	8.67	24	0	3.752	8.53	24	0
13	3.683	8.69	25	0	3.759	8.51	25	0
14	3.721	8.60	440	0	3.833	8.35	440	0
15	3.681	8.69	24	0	3.754	8.52	24	0
16	3.684	8.69	24	0	3.752	8.53	24	0
17	3.745	8.55	24	0	3.749	8.54	24	0
18	3.684	8.69	24	0	3.754	8.52	24	0
19	3.682	8.69	24	0	3.753	8.53	24	0
20	3.686	8.68	24	0	3.795	8.43	344	1
21	3.678	8.70	24	0	3.752	8.53	38	0
22	3.680	8.70	24	0	3.753	8.53	24	0
23	3.730	8.58	338	1	3.757	8.52	24	0
24	3.681	8.69	43	0	3.751	8.53	24	0
25	3.679	8.70	24	0	3.751	8.53	24	0
26	3.675	8.71	24	0	3.755	8.52	24	0
27	3.674	8.71	24	0	3.763	8.50	24	0
28	3.676	8.70	24	0	3.758	8.52	24	0
29	3.687	8.68	24	0	3.755	8.52	24	0
30	3.685	8.68	24	0	3.756	8.52	24	0
31	3.713	8.62	432	0	3.783	8.46	430	0
32	3.679	8.70	24	0	3.751	8.53	24	0
33	3.674	8.71	24	0	3.757	8.52	24	0
34	3.673	8.71	24	0	3.756	8.52	24	0
35	3.671	8.72	24	0	3.756	8.52	24	0
36	3.671	8.72	24	0	3.753	8.53	24	0
37	3.672	8.72	24	0	3.838	8.34	24	0
38	3.672	8.72	24	0	3.759	8.51	24	0
39	3.672	8.72	24	0	3.751	8.53	24	0
40	3.677	8.70	24	0	3.750	8.53	24	0
41	3.669	8.72	24	0	3.748	8.54	24	0
42	3.670	8.72	24	0	3.748	8.54	24	0
43	3.762	8.51	24	0	3.750	8.53	24	0
44	3.674	8.71	24	0	3.748	8.54	24	0
45	3.673	8.71	24	0	3.746	8.54	24	0
46	3.680	8.69	24	0	3.757	8.52	24	0
47	3.674	8.71	24	0	3.758	8.51	24	0
48	3.699	8.65	48	0	3.777	8.47	48	0
49	3.667	8.73	24	0	3.756	8.52	24	0
50	3.670	8.72	24	0	3.749	8.53	24	0
51	3.670	8.72	24	0	3.797	8.43	24	0
52	3.670	8.72	24	0	3.752	8.53	24	0
53	3.669	8.72	24	0	3.748	8.54	24	0
54	3.668	8.72	24	0	3.755	8.52	24	0
55	3.671	8.72	24	0	3.752	8.53	24	0
56	3.667	8.73	24	0	3.758	8.52	24	0
57	3.693	8.66	24	0	3.756	8.52	24	0
58	3.667	8.73	24	0	3.754	8.52	24	0
59	3.728	8.58	24	0	3.756	8.52	24	0
60	3.664	8.73	24	0	3.753	8.53	24	0
61	3.665	8.73	24	0	3.749	8.54	24	0
62	3.669	8.72	24	0	3.746	8.54	24	0
63	3.664	8.73	24	0	3.745	8.54	24	0
64	3.673	8.71	24	0	3.750	8.53	24	0
65	3.691	8.67	48	0	3.815	8.39	364	1
66	3.667	8.73	24	0	3.751	8.53	80	0
67	3.666	8.73	24	0	3.751	8.53	24	0
68	3.666	8.73	24	0	3.751	8.53	24	0
69	3.665	8.73	24	0	3.752	8.53	24	0
70	3.667	8.73	24	0	3.746	8.54	24	0
71	3.698	8.65	80	1	3.750	8.53	24	0
72	3.692	8.67	292	0	3.748	8.54	24	0
73	3.672	8.72	24	0	3.747	8.54	24	0
74	3.668	8.72	24	0	3.746	8.54	24	0
75	3.666	8.73	24	0	3.746	8.54	24	0
76	3.665	8.73	24	0	3.748	8.54	24	0
77	3.663	8.74	24	0	3.745	8.54	24	0
78	3.675	8.71	24	0	3.748	8.54	24	0
79	3.667	8.73	24	0	3.750	8.53	24	0
80	3.665	8.73	24	0	3.751	8.53	24	0
81	3.665	8.73	24	0	—	—	—	—
82	3.698	8.65	422	0	—	—	—	—

The ten rebuild cycles on the laptop

Heap figures are in bytes. Heap while running is measured above the starting heap of 1,552,664 bytes; heap after closing is the whole heap in use.

Cycle	Build	Deliveries/s	Heap while running bytes	Heap after closing bytes	Close
1	0.48 s	2.61 G	2,079,675,352	30,999,520	0.50 s
2	0.32 s	3.19 G	1,129,792,936	27,016,432	0.25 s
3	0.17 s	3.22 G	1,043,115,336	27,016,432	0.23 s
4	0.34 s	3.23 G	1,044,832,312	27,016,432	0.23 s
5	0.32 s	3.14 G	1,043,628,960	27,016,432	0.23 s
6	0.29 s	3.18 G	1,044,101,976	27,016,416	0.23 s
7	0.19 s	3.16 G	1,043,112,408	27,016,152	0.23 s
8	0.17 s	3.13 G	1,043,260,984	27,016,152	0.23 s
9	0.34 s	3.21 G	1,043,522,600	27,016,152	0.23 s
10	0.17 s	3.10 G	1,043,051,360	27,016,152	0.23 s

The warmup rounds, not counted above

Run	Round	Seconds	Deliveries/s	Bytes per visit	Collections
1	Warmup 1	4.419	7.24 G	951	1
1	Warmup 2	3.752	8.53 G	359	1
2	Warmup 1	4.284	7.47 G	962	1
2	Warmup 2	3.804	8.41 G	359	1