Scala future, Sing#

[Walter Bright]

Jari-Matti Mäkelä wrote:
> I meant this
> 
> "Another important example of this kind of optimization is class-hierarchy-
> based optimization. A virtual method invocation, for example, involves 
> looking at the class of the receiver object for the call to discover which 
> actual target implements the virtual method for the receiver object. 
> Research has shown that most virtual invocations have only a single target 
> for all receiver objects, and JIT compilers can generate more-efficient code 
> for a direct call than for a virtual invocation. By analyzing the class 
> hierarchy's state when the code is compiled, the JIT compiler can find the 
> single target method for a virtual invocation and generate code that 
> directly calls the target method rather than performing the slower virtual 
> invocation. Of course, if the class hierarchy changes and a second target 
> method becomes possible, then the JIT compiler can correct the originally 
> generated code so that the virtual invocation is performed. In practice, 
> these corrections are rarely required. Again, the potential need to make 
> such corrections makes performing this optimization statically troublesome."
> 
> http://www.ibm.com/developerworks/java/library/j-rtj2/index.html

I'm not quite sure what that means, but I think it means nothing more 
than noting that a method is not overridden, and so can be called directly.

Currently, this optimization happens in D if a method or class is 
annotated with 'final'. It is possible for the compiler to do this if 
flow analysis can prove the direct type of a class reference, but the 
optimizer currently does not do that. It is also possible for the 
compiler to determine that methods are final automatically if it knows 
about all the modules that import a particular class.