Virtual extension methods -- a strawman design

[Doug Lea]

On 05/15/10 13:34, Brian Goetz wrote:
>> A compiler only approach will not work because introducing a new method in
>> an interface breaks the *binary* compatibility.
>>
>> like Neal, I am in favor of a VM only approach.
>
> As you correctly point out, the choices are VM-only and VM+compiler, and
> compiler-only is not an option.  I see pros and cons for both options.  The
> VM+compiler option is obviously more work for us, but seems likely to reduce
> the impact on the tools ecosystem.  Ignoring the "which is more work"
> aspect, can you outline what you see as the advantages of the VM-only
> approach?
>

Another choice is VM plus linking tools.
If front-end compilers stay dumb and just put out the "obvious" code,
it would be a good idea to offer developers a choice of
whether they wanted fast vs dynamic via optional additional tools.
With closures, it seems a sure thing that people will want to develop
such tools anyway to get better performance for constructs that
VMs don't always cope all that well with. As was pointed out last
week by Nathan Bryant:

> No JVM-level recognition that an object is a closure, and can hence be
> eliminated, as it can be with Scala's closure elimination (if the HOF
> can also be inlined.) The JVM seems to add something like an unavoidable
> machine word access to every polymorphic call site, even if they are
> supposedly inline-cached and not megamorphic, even inside a loop. Result
> that I've seen is approximately a 2x slowdown on toy microbenchmarks
> like "sum an array of integers" if implemented with any form of closures
> other than something that can be @inline'd in Scala. (And even in Scala,
> most HOF's are virtual hence can't be inlined.) I for one would like to
> see usable inlining in a language that /encourages/ the use of closures
> in every for loop.

There is no need for front-end compilers to do this inlining etc either.
It strikes me that jar-packaging tools might turn into optimizing
linking tools to address a bunch of related performance problems at
once.


-Doug