If you are part of the HFT crowd who uses the JVM then you know who the author, Cliff Click, is.
His Blogs (former and current) are goldmines for high performance JVM information.
http://www.azulsystems.com/blog/author/cliff
http://www.cliffc.org/blog/
I had one CTO of a public HFT firm tell me that short of FPGA's Azul's pause-less GC (https://www.azul.com/products/zing/pgc/) was the biggest performance win they'd had in the past few years, note: this was a few years ago.
EDIT: someone emailed asking for how HFT firms write their java code. I haven't written java in 3 years so I'm probably not the best person to author a list but this is what I'd include:
In order of importance:
- Measure, measure, measure. Every HFT firm can tell you to the nanosecond, as much as that's possible, what their time is from receiving a packet to when it's replied to. Focus as much, if not more on the 95%, 99% times as the average time.
This time increasing is considered a bug in the same way that an app crashing due to user input is considered a bug, which is to say that you just don't ship with this kind of bug.
- no GC's, everything else starts to become less important if the GC is called every 30 seconds. Some guys will have only one GC call a day, which means you have a really large Eden GC space
- short call stacks, and no recursion
- one physical core per thread
- non locking data structures and use the one writer principle where possible
- don't use the kernel if possible, ie solar flare Ethernet cards that have userland drivers
- cache friendly data structures
Watch this video:
https://www.youtube.com/watch?v=iINk7x44MmM
His Blogs (former and current) are goldmines for high performance JVM information.
http://www.azulsystems.com/blog/author/cliff
http://www.cliffc.org/blog/
I had one CTO of a public HFT firm tell me that short of FPGA's Azul's pause-less GC (https://www.azul.com/products/zing/pgc/) was the biggest performance win they'd had in the past few years, note: this was a few years ago.
EDIT: someone emailed asking for how HFT firms write their java code. I haven't written java in 3 years so I'm probably not the best person to author a list but this is what I'd include:
In order of importance:
- Measure, measure, measure. Every HFT firm can tell you to the nanosecond, as much as that's possible, what their time is from receiving a packet to when it's replied to. Focus as much, if not more on the 95%, 99% times as the average time.
This time increasing is considered a bug in the same way that an app crashing due to user input is considered a bug, which is to say that you just don't ship with this kind of bug.
- no GC's, everything else starts to become less important if the GC is called every 30 seconds. Some guys will have only one GC call a day, which means you have a really large Eden GC space
- short call stacks, and no recursion
- one physical core per thread
- non locking data structures and use the one writer principle where possible
- don't use the kernel if possible, ie solar flare Ethernet cards that have userland drivers
- cache friendly data structures
Watch this video: https://www.youtube.com/watch?v=iINk7x44MmM