That is exactly what I did. It was much less elegant and performant, though, than my initial solution with Common Lisp and C which basically allocated buffers in memory and mapped them with huge pages so that memory access don't ever require switch to kernel for mapping.

We also had custom Intel CPUs that are auctioned individually. And cutthrough switches that stream the IP packet immediately when they receive the IP header, before they receive the payload. I have calculated that if the message from exchange was a beam of light it would be delayed by less than a meter.

> would be delayed by less than a meter

That's just latency to your NIC, right? 1 meter ~ 3 ns ~ 9 CPU cycles at 3 GHz, less than the integer pipeline depth last I checked.

Latency through switch (ie. how much the switch added compared to if the signal traveled unimpeded in vacuum).

Decade ago.

If that's your memory management strategy, then what do you actually gain by using Java?

May as well just use C and never free your memory. Lots of memory management issues go away if you never free memory.

Not all your services/code needs to have the lowest latencies so you can have a team which just needs to be able to translate the business requirements and a couple of people to optimise the critical code.

If you have multiple processes each with 24 GB of Eden space and you can produce 1 GB/hour of garbage in each service and still only GC once a day.

It works until it doesn't and you lose a ton of money