A very interesting expert panel
This expert panel on the Future of the JVM includes Cliff Click, Charlie Hunt and Doug Lea.
A number of interesting questions are asked and while I agree the points raised, I am reminded of something I state often; usually simplicity and maintainability is more important than performance.
A number of interesting questions are asked and while I agree the points raised, I am reminded of something I state often; usually simplicity and maintainability is more important than performance.
Q: struct, do we need them?
The general discussion is broadly in favour of them but Cliff Click raises the point that the performance issue may be solved in the next five to seven years.
My point of view: The real value of structs is the ability to define types efficiently. e.g. instead of using String for a "name", an long for an "account id", a BigDecimal for a "price", you can define structs of those types and use those types in methods and classes without worrying about performance or overhead.
Instead of
Map> map = ...
public Double update(String name, long accountId, double price)
you can write
Map> map = ...
public Price update(Name name, AccountId accountId, Price price)
without concern for performance or overhead. This is not just a typedef, as these field could be a combination of primitives or possibly reference (though the later would complicate GC)
Q: Support for Multi-Field Value types, i.e. wider than 64-bits?
I would like to see 128-bit integers and 128-bit floating point. There are many uses for more precise calculation and storing larger values. Current BigDecimal and BigInteger is very cumbersome compared with using specialised types, which is not elegant, or as efficient as they could be either.
IMHO, One thing which would help BigDecimal and BigInteger is providing operators.
Q: Hardware affinity and multi-core programming?
Multi-core programming is in the 1000 cores range in the future. They felt that general purpose programming for that many cores doesn't been solved yet.
Doug Lea wasn't very keen on pinning threads to cores. It wasn't clear why, but perhaps he felt it tried to solve a problem best solved another way.
My view: I believe thread affinity is only useful for very specific use cases such as minimising jitter in the 99% to 99.99% range. If you are not concerned about this, I don't think the complexity is worth any benefit you will see.
Q: Memory Barrier Primitives
This will be available in Java 8 via intrinsics in Unsafe which hides away these features. It will provide the functionality that C++v11 provides in it's new memory model.
My view: From using shared memory over memory mapped files, some primitives which work in this mode would be very useful. At present I use a subset I have found to work on amd64/x64 which has the obvious problem that it might not work on ARM and other hardware.
Q: JVM Profiles
Different systems need different trade offs and different Java profiles. They discussed embedded and mobile profiles.
My View: a more real time mode or profile would be useful. One which can load classes and JIT code more aggressively on start up without the disadvantages of getting slower code in the long run if you reduce the CompileThreshold
Q: Concurrent Programming Fads
Most of the discussion was around STM and HTM. The view being that STM may have yielded some interesting STM like models, and HTM may one day be more useful than it is today.
My View: In dicussions about making mulit-threading easier, it often appears to be forgotten why we using multi-threads. The assumption is often that since we have multiple cores, we must use them. This is like saying we have TB of disk space so we should try to make sure it is always full. The reason for multi-threads is because this can improve performance and possibly consistency of performance. If you have forgotten this, then you are likely to get a solution which is not only more complicated than a single threaded solution, but also slower.
It is a bit of an honour that Chronicle was noted under the "fad" banner. ;)
Q: Most wanted and worst ideas in the JVM.
My View: worst feature was a synchronized StringBuffer. I have blogged about this a couple of times. I would add mutable Date objects.
Best feature I would like to see is escape analysis which really worked. If you have a for-each loop which creates an Iterator which is a local variable completely under Java's domain, it should be able to eliminate the object. It should be able to remove locking on local variables (which live and die in a method). There are many common but trivial examples where objects are not put on the stack.
Great article, thanks.
ReplyDeleteCan you please expand on your thoughts about a mutable date object? I'm curious as use cases where mutability would be beneficial.
Most of the articles I've read of yours focus on concurrency and/or high performance. Most books I've read on concurrency espouse the benefits of immutability.
Curious for your take.
Thanks again for another great article,
Marty
If you have data shared between threads, it is a lot easier to write and debug if the data uses immutable values. i.e. you might have a mutable collection, or queue, but the data you hold in it is immutable. This is where Date could be a problem as it is mutable though it is rarely used this way. It can be treated as immutable, not by good design but by the fact most people don't use the setTime() method.
ReplyDeleteMy preference is to use the actor pattern and have a series of single threaded "engines" which send messages to each other via systems such as Chronicle. In this model, each thread has most data local to a thread and mutable. The benefit of using mutable state is the code is simpler (you are effectively writing single threaded code), it produces far less garbage, and in extreme cases, you can have systems which GC less than once per day (which is the goal of the projects I work on) BY less than once per day, I inlcude minor collections as well.
Using mutable state in one thread, you write simple, single threaded code, you don't need to worry about locking, you can minimise GCs, and each thread can run as independently as possible.