Peter Lawrey is always working on pushing the boundaries of Java performance so there's really no reason you shouldn't be keeping up with his blog. I took the opportunity to catch up with Peter this month with the amount of commits currently going into the Chronicle-Engine project that he works on.
To start, just give us a quick introduction about your background and your current work.
I'm a Java Champion with 20 years experience in high performance Java applications such as trading, risk and data distribution systems. For my day job I'm CEO of Chronicle Software which specializes in creating software to make really fast data accessible to every Java developer. I'm also Founder of the Performance Java User's Group (1600 members) and my blog VanillaJava has had over 3 million hits.
What are you and your coworkers sprinting toward right now as a goal?
We have released a stable version of Chronicle-Engine and we are looking to round out the testing. We've spent the last few years developing software to make data in Java super fast, with our flagship products Chronicle-Queue and Chronicle-Map. Chronicle-Engine is a layer above Chronicle-Queue and Chronicle-Map created to support data virtualisation. The goal of Chronicle-Engine is all about simplification. Developers can use a standard ConcurrentMap or Pub/Sub API and the actual implementation is abstracted away and can be replaced. e.g. it can be pure in memory, flat files, Chronicle Map, JDBC, LDAP or a custom back end store. This allows developers to write simple code for reactive environments without having to learn new APIs for each possible back-end store. Our real time query API is based on the Streams API where your lambdas are executed on the server for improved performance.
To make data access to all platforms we are looking to support Chronicle Engine as an NFS server. This means any NFS client can access the engine from any language.
# map.put("Hello", "World") $ echo World > Hello # System.out.println(map.get("MOTD")); $ cat MOTD
Note: the file name is the key of the underlying store, and the content of the file is the value.
You've had several successful talks at various conferences. What are the topics you've been covering on the conference circuit in the past two years?
I have been talking about lambdas in Java 8 and how cool they are, in particular how the Java 8 JVM can place objects on the stack to eliminate garbage automatically. We use distributed lambdas to make writing client side code to execute on the server easier. i.e. on the client you use a lambda, but it is sent to the server for execution, performance, and atomicity. e.g.
// print the name of the users 21 or over, including as users added. map.entrySet().query() .filter(e -> e.getValue().getAge() >= 21) // executed on the server .map(e -> e.getKey()) // executed on the server .subscribe(System.out::println); // executed on the client.
I have also been talking about storing very large data sets in Java by using native memory. For example, one client holds 70 GB of data in Java with notional heap usage. After a process restart, making all that data available adds just 10 milli-seconds. We have two clients who are persisting data at peak rates of over 10 million events per second without message loss.
What are some of the questions that you get frequently at your presentations and from the community?
The most common question is how big is the company and where is our office. We have 4 full time developers and 4 part time staff. We either work from home or on site.
Is there anything that you're really keeping an eye on in Java 9 related to the work you do?
The big thing for me is VarHandle. How is it going to work for thread safe off heap memory given that we use this so much? We can still use Unsafe in Java 9 but would rather have a standard API to work from. Even better would be user defined intrinsics, possibly in Java 10. That would be really cool.
Speaking of Java 9, what do you think about the plans to move the functionality of sun.misc.Unsafe to Java's public API in Java 9, which has gotten a lot of visibility in the last couple of weeks?
The problem as I see it is that they are planning to remove something without having a replacement - or at least a replacement in which we can be confident (it's not even in the EA version of Java 9 yet) .
They have taken away tools.jar but the Compiler API has been around since Java 6 so this shouldn't be a big deal.
Another concern is that the designers haven't shown much understanding as to why Unsafe was being used in the first place. They know it has been used, but feel it should never have been used and they are the only ones who should ever have needed it. We could have used JNI but is doing that really any safer?
Are there any interesting or useful technologies you've learned about in the last couple of months that you want to talk about?
I think two projects have grown more impressive over time. These are JITWatch which allows you to see how a process is compiled, right down to the machine code for a line of Java. Another is JMH which has made writing micro-benchmarks much easier. They have been around a while but recent updates mean you should have another look at them.
Or just any other topic that you think is interesting right now that you didn't talk about yet?
I think it is worth repeating on how important Inlining and Escape Analysis is. In combination, these can move a short lived object to the stack or even eliminate it entirely. This is essential for the performance of Stream API with Lambdas, but it works for all Java objects. Short lived objects you might have avoided in the past might not matter (at least once the JVM has warmed up) From a low latency perspective this is significant as it means you can use objects again provided the JVM can eliminate them for you.