peter_lawrey

TL;DR: Markdown for AI working documents, AsciiDoc for curated human-reviewed specs, HTML only as a publishing target.

AI has improved over the last 6 months, with quality in the mid-range. It takes less effort to get it to produce a mediocre-to-average-quality solution. In many cases, this is good enough. For production, while we still need a rewrite, there is less effort required to prototype it first.

A common mistake appears to be that only when women have fewer than 1 child does the population drop long term...

This post explores using AI as a mock User, something AI is particularly suited for. - AI remembers nothing from previous tests by default. - It has a broad knowledge set - It reads most of the documentation

In this post I look at a simple event to response latency benchmark, MarketDataSnapshot to NewOrderSingle at 50K/s for 30 minutes using JLBH to test Chronicle-FIX. The goal is to compare a system which is doing redundant work (in this case logging each message using SLF4J), compared with not logging (Chronicle-FIX records every message internally using Chronicle Queue) and how this changes the choice of Garbage Collector

Thank you for the feedback

Good feedback

This is a high-level article; for lower-level details, I also posted.

https://blog.vanillajava.blog/2026/06/testing-java-memory-ma...

https://blog.vanillajava.blog/2026/06/why-you-should-tun-cod...

Suggestions welcome, it can be hard to know what to include or not.

7 Frequently Asked Questions about Low-latency Microservices in 7 minutes

Most Iterators should be placed on the stack anyway. If they are not and you have a random access collection like ArrayList you can use an index, but this is rarely needed. If you are going to change code, perhaps Stream(s) are a better choice, these are also placed on the stack most of the time.

A friend of mine is working at Oracle on collections that support primitives e.g. List<int>, Set<long> https://openjdk.org/jeps/8261529

Iterators tend to be placed on the stack in hot code. In the benchmark I had to make sure these object weren't optimised away.

Mutable objects have their own issues, which can catch people out by surprise. Having good test coverage is important.

Reusing your objects can be confusing for other developers. You need to be careful with anything exposed via an API, however internally you can me more optimised.

In each case the default settings were used (i.e. no options were provided). In both Java 8 (Parallel GC) and Java 11+ (G1), As the GC was a small portion of the time, changing the GC wasn't expected to make a difference anyway.

The GC isn't involved with allocation, the expensive bit here. The GC handles the clean up. The allocations create memory pressure that can easily saturate the bus to DDR if you are not careful.

Right, it's the total object count at runtime that matters, not how many lines of code could create an object.

This is where using a profiler like YourKit or Flight Recorder is your friend. It will show you the objects that can't be optimised away and where code bottlenecks are. It's hard to determine this in advance for Java.

or FPGA

Something not generally mentioned is that Java can inline what would be virtual methods in C++, it can also remove them as behaviour changes or code is unloaded.

In the real world projects, with the developers you can get, and the time frames you are given, not the developer you might want and any amount of time, Java can be a better choice.

You can have a look at https://github.com/OpenHFT however it is designed to have most data off heap.

Not if you need to be able to hire a large number of developers for an investment bank. London has around 300K developers, many in fintech. There isn't that many Rust developers with say 10 -15 years fintech development experience.

That assumes your commercial model is based on an arms races of just being the fastest. This is not a model investment banks have used for some time.

Or you can use Apache 2.0 open source licensed libraries which are used in low latency trading systems and pay for the level of support your organisation needs and no more.

https://github.com/OpenHFT

If you can have any developers you want and have unlimited time, C++ is a good choice.

However, if you are a bank, which not where every developer wants to work, you have a limited budget, limited time and you have a project which isn't technically exciting (but can make a lot of money for the bank) you might find the developers you have who understand the business are more productive in Java and the resulting trading system is faster than the one they might have written in C++.

When you have some teams developing in Java and some in C++ you get to see which teams are more productive for your organisation.