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.

The GC can pace the allocation when it can't keep up.

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.