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.
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.
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.