Improving the JVM for Scala [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

What changes to the JVM would most benefit the Scala compiler and runtime?

The dynamic languages will benefit greatly in performance from the introduction of the InvokeDynamic byte code scheduled to arrive in JVM 7 and Scala will probably benefit from tail recursion (not sure if it will appear in JVM 8 or later).

What other changes could Scala, with its present feature set, benefit from in the JVM? Are these changes on the horizon?

Specifically, are there changes to the JV开发者_开发问答M that would improve performance with closures and functions-as-objects?

Basically, everything that John Rose has been campaigning for :)

Fixnums - To eliminate the cost of boxing/unboxing primitives.
Method Handles - Would speed up higher-order functions and allow the JVM to optimise them more effectively. SAM types can sometimes require an awkward flip/flopping between monomorphic and megamorphic call sites that prevents inlining.
Continuations - To support asynchronous/concurrent design, as per node.js
Interface Injection - Simplify mixin composition and the implementation of roles, as well as eliminating the need for generating some intermediate classes and making structural types possible without reflection in many cases.
Tail-call optimisation - Should be a no-brainer :)

Reification is often quoted as something that would benefit Scala's pattern matching, but this would come at a high cost in terms of interop, given the different variance schemes that the two languages use. At this point, I believe that reification may actually cause more harm than it would do good.

I also think it unreasonable to expect anything that would break backwards compatibility in Java. That just ain't gonna happen.

There are a couple of features of Scala that would be better implemented in the JVM, such has:

Generics that are accessible at runtime. At the moment, scalac saves the types of generics as hidden fields (if the class in question is a case class). This makes generics in case classes unnecessarily expensive though.
Declaration-site variance. Scala specifies the variance of type parameters at the definition site, while Java does so at the call site. This is very unlikely to get fixed though, since it would break all existing Java generic code.
Tail call optimization. Scalac can do some tail call optimization on it's own, but only in the simplest (self-recursive) case. Any other tail calls will use stack space like in the JVM.
Removal of null pointers. Scala can already handle null refs with Option[A], but because of being on the JVM, the reference to the option itself could be null, or it's parameter could be null. So you don't get a guarantee of non-null-ness like in say Haskell.

EDIT: Added declaration-site variance to list.

Value types would help quite a bit performance wise for tuples and case classes. Escape analysis helps reduce heap allocations of such objects a bit, but at the moment the JVM can't inline some method calls aggressively enough thus can't eliminate heap allocations for these small immutable objects. This leads to heap trashing and 3-4x higher execution time.

Value types also helps increase data locality and reduce memory usage. For example, in a simple Array[(Int, Int)] each array entry will have an overhead of one pointer + object header. With value types this overhead could be eliminated completely.

People often focus on InvokeDynamic - without realizing that the MethodHandles framework has plenty of other advantages, even if the method references that MH provides are never dynamically invoked.

MethodHandles are almost like a performant form of "Reflection done right".

Any language which makes heavy use of reflection may well be able to get benefits from using MethodHandles inside the language runtime.