=== Summary so far ===

=== Summary so far ===

As a result we have implementation of [[closures|lambdas]] that is needlessly forgetting the type information gained during compilation, re-creates it during each startup, is generating [[bytecode]] on the fly. It is even surprising it performs acceptably (which probalby took many nights of the [[HotSpot]] team members, but ''when there is a will, there is a way'': John Rose was so motivated to show [[invokeDynamic]] is useful, so he did it).

As a result we have implementation of [[closures|lambdas]] that is needlessly forgetting the type information gained during compilation, re-creates it during each startup, is generating [[bytecode]] on the fly. It is even surprising it performs acceptably (which probably took many nights of the [[HotSpot]] team members, but ''when there is a will, there is a way'': John Rose was so motivated to show [[invokeDynamic]] is useful, so he did it).

No surprise [[InvokeDynamic]] is not supported by [[Android]]'s [[Dalvik]] [[VM]] (and in fact it should never be, unless [[Android]] wants to attract [[Ruby]] and other dynamic language developers). [[Java]] language does not need it and if you care about [[Java]] language, forget about [[invokeDynamic]]!

No surprise [[InvokeDynamic]] is not supported by [[Android]]'s [[Dalvik]] [[VM]] (and in fact it should never be, unless [[Android]] wants to attract [[Ruby]] and other dynamic language developers). [[Java]] language does not need it and if you care about [[Java]] language, forget about [[invokeDynamic]]!

=== The Problem ===

=== The Problem ===

The unnecessary loose of types is problematic for [[VM]]s that are supposed to run in restricted environment - e.g. [[Bck2Brwsr]] or (as far as I heard) [[Java]] ME 8. We are running in restricted [[environment]], we can't consume these resources by trying to generate new classes. Just in time compilation may be too expensive, it is much easier to generate the right execution format ahead-of-time (both for [[Bck2Brwsr]] and for [[Java]] ME 8).

The unnecessary loss of types is problematic for [[VM]]s that are supposed to run in restricted environment - e.g. [[Bck2Brwsr]] or (as far as I heard) [[Java]] ME 8. We are running in restricted [[environment]], we can't consume these resources by trying to generate new classes. Just in time compilation may be too expensive, it is much easier to generate the right execution format ahead-of-time (both for [[Bck2Brwsr]] and for [[Java]] ME 8).

Another issue is related to reflection. [[Method Handle]]s are (due to their dynamic nature) a specific form of reflection. While doing method lookup one identifies the desired method (or field, or setter) by name. One can reference public or private methods. It is not known in advance which methods will be requested - one needs to invoke the bootstrap method to find that out. As such it is really hard to do compile time optimizations (like shortening method names). Again problem for for small, limited environments.

Another issue is related to reflection. [[Method Handle]]s are (due to their dynamic nature) a specific form of reflection. While doing method lookup one identifies the desired method (or field, or setter) by name. One can reference public or private methods. It is not known in advance which methods will be requested - one needs to invoke the bootstrap method to find that out. As such it is really hard to do compile time optimizations (like shortening method names). Again problem for for small, limited environments.

[[Java]] and [[JVM]] needs to get smaller (to compete with emerging and improving competitive technologies; think of [[V8]] and [[NodeJS]]), not bigger. Complicating them just makes it harder to port [[Java]] to new, small areas of use.

[[Java]] and [[JVM]] needs to get smaller (to compete with emerging and improving competitive technologies; think of [[V8]] and [[NodeJS]]), not bigger. Complicating them just makes it harder to port [[Java]] to new, small areas of use.

Should not we rather think twice before repeating the [[invokeDynamic]] failure [[Value classes|again]]? Should not we fix the [[invokeDynamic]]/[[Closures|lamda]] issue - for example by removing/deprecating [[invokeDynamic]] from future [[JVM]] spec and replacing it with '''newFromAMethod''' [[bytecode]]?

Should not we rather think twice before repeating the [[invokeDynamic]] failure [[Value classes|again]]? Should not we fix the [[invokeDynamic]]/[[Closures|lamda]] issue - for example by removing/deprecating [[invokeDynamic]] from future [[JVM]] spec and replacing it with a '''newFromAMethod''' [[bytecode]]?

I believe the same style could have been used for [[InvokeDynamic]]. If [[HotSpot]] wanted to give [[Ruby]] & co. more effective way to handle method dispatch, there could be some extension of the base [[ByteCode]] that [[Ruby]] and [[HotSpot]] could use to talk to each other without modifying [[JVM]] specification at all.

I believe the same style could have been used for [[InvokeDynamic]]. If [[HotSpot]] wanted to give [[Ruby]] & co. more effective way to handle method dispatch, there could be some extension of the base [[ByteCode]] that [[Ruby]] and [[HotSpot]] could use to talk to each other without modifying [[JVM]] specification at all.

Probably such ''extensive'' approach would be used, if the [[JVM]] team and [[HotSpot]] team would not be one! If there were more implementations of [[JVM]] spec that would be treated seriously (which was true in case of [[AsmJs]] as [[Mozilla]] needs to negotiate changes to [[JavaScript]] specification with others: [[Safari]], [[Chrome]], etc.).

Probably such ''extensive'' approach would be used, if the [[JVM]] team and [[HotSpot]] team would not be one! If there were more implementations of [[JVM]] spec treated seriously (which was true in case of [[AsmJs]] as [[Mozilla]] needs to negotiate changes to [[JavaScript]] specification with others: [[Safari]], [[Chrome]], etc.).

=== Diverging Future ===

=== Diverging Future ===

Something like '''newFromAMethod''' that would specify the resulting interface to generate, the method to call and additional parameters to pass to it.

Something like '''newFromAMethod''' that would specify the resulting interface to generate, the method to call and additional parameters to pass to it.

Some may say that adding new instruction into [[JVM]] needs to be done with care. But those who have seen John's new attempt in the area of [[Value classes]] have to realize that adding new instructions into [[JVM]] is no longer tabu. In such case adding '''newFromAMethod''' that closely mimics necessary [[Java]]8 semantics should be no brainer.

Some may say that adding new instruction into [[JVM]] needs to be done with care. But those who have seen John's new attempt in the area of [[Value classes]] have to realize that adding new instructions into [[JVM]] is no longer taboo. In such case adding '''newFromAMethod''' that closely mimics necessary [[Java]]8 semantics should be no brainer.

Porting that to limited [[VM]]s like [[Bck2Brwsr]] or [[Java]] ME would be way easier as all the typechecks are performed by [[Javac]] and the rest is just about wiring the method call. All the information is in the classfile. Way easier to extract it than to execute [[invokeDynamic]]'s bootstrap method.

Porting that to limited [[VM]]s like [[Bck2Brwsr]] or [[Java]] ME would be way easier as all the typechecks are performed by [[Javac]] and the rest is just about wiring the method call. All the information is in the classfile. Way easier to extract it than to execute [[invokeDynamic]]'s bootstrap method.

=== Getting Dynamic ===

=== Getting Dynamic ===

The primary goal of John Rose was to support dynamic languages - e.g. languages where one knows (almost) no type information until the program actually runs. That means one can effectively type (in this [[JVM]] context: effectively generate [[bytecode]]) only when one knows the actual types. To address all these "deffered" needs the new [[invokeDynamic]] [[bytecode]] operand had been introduced. It does not hardcode the actual invocation, but once invoked, it calls back to let the "supervising" software (like your [[JRuby]] implementation) to analyse the actual call parameters and generate sequence of [[MethodHandle]] transformation (possibly a bit of [[wikipedia:currying|currying]], mostly type conversions) to effectively match the actual types of method arguments.

The primary goal of John Rose was to support dynamic languages - e.g. languages where one knows (almost) no type information until the program actually runs. That means one can effectively type (in this [[JVM]] context: effectively generate [[bytecode]]) only when one knows the actual types. To address all these "deffered" needs the new [[invokeDynamic]] [[bytecode]] operand had been introduced. It does not hardcode the actual invocation, but once invoked, it calls back to let the "supervising" software (like your [[JRuby]] implementation) analyse the actual call parameters and generate sequence of [[MethodHandle]] transformation (possibly a bit of [[wikipedia:currying|currying]], mostly type conversions) to effectively match the actual types of method arguments.

=== Drawbacks ===

=== Drawbacks ===

=== Benefits ===

=== Benefits ===

Implementing different languages on top of [[HotSpot]] virtual machine is of different complexity. When John Rose pushed forward his [[invokeDynamic]] vision, he claimed that the most problematic thing is to properly and effectively dispatch methods calls. Not every language uses the [[Java]] rules. Some support type conversions, implicit arguments. Some can dynamically alter the existing dispatch target or strategies. More about that in an excellent summary [http://blogs.sun.com/jrose/entry/vmil_paper_on_invokedynamic Bytecodes meet Combinators]. [[I]] really liked that paper and [[I]] continue to like it. It matches my functional heart: with [[MethodHandle]] (basically a pointer to method of some signature (for example ''plus'' would take two ints and return their sum as an int) and an object - a receiver to call the method on) a method invocation is finally first class citizen in the [[VM]]. One can do [[wikipedia:Currying|currying]] & co. - all the goodies functional languages had for ages.

Implementing different languages on top of [[HotSpot]] virtual machine is of different complexity. When John Rose pushed forward his [[invokeDynamic]] vision, he claimed that the most problematic thing is to properly and effectively dispatch methods calls. Not every language uses the [[Java]] rules. Some support type conversions, implicit arguments. Some can dynamically alter the existing dispatch target or strategies. More about that in an excellent summary [http://blogs.sun.com/jrose/entry/vmil_paper_on_invokedynamic Bytecodes meet Combinators]. [[I]] really liked that paper and [[I]] continue to like it. It matches my functional heart: with [[MethodHandle]] (basically a pointer to method of some signature - for example ''plus'' would take two ints and return their sum as an int - and an object - a receiver to call the method on) a method invocation is finally first class citizen in the [[VM]]. One can do [[wikipedia:Currying|currying]] & co. - all the goodies functional languages had for ages.

But there is a hidden catch...

But there is a hidden catch...

=== Benefits ===

=== Benefits ===

Implementing different languages on top of [[HotSpot]] virtual machine is of different complexity. When John Rose pushed forward his [[invokeDynamic]] vision, he claimed that the most problematic thing is to properly and effectively dispatch methods calls. Not every language uses the [[Java]] rules. Some support type conversions, implicit arguments. Some can dynamically alter the existing dispatch target or strategies. More about that in an excellent summary [http://blogs.sun.com/jrose/entry/vmil_paper_on_invokedynamic Bytecodes meet Combinators]. [[I]] really liked that paper and [[I]] continue to like it. It matches my functional heart: with [[MethodHandle]] a method invocation is finally first class citizen in the [[VM]]. One can do [[wikipedia:Currying|currying]] & co. - all the goodies functional languages had for ages.

Implementing different languages on top of [[HotSpot]] virtual machine is of different complexity. When John Rose pushed forward his [[invokeDynamic]] vision, he claimed that the most problematic thing is to properly and effectively dispatch methods calls. Not every language uses the [[Java]] rules. Some support type conversions, implicit arguments. Some can dynamically alter the existing dispatch target or strategies. More about that in an excellent summary [http://blogs.sun.com/jrose/entry/vmil_paper_on_invokedynamic Bytecodes meet Combinators]. [[I]] really liked that paper and [[I]] continue to like it. It matches my functional heart: with [[MethodHandle]] (basically a pointer to method of some signature (for example ''plus'' would take two ints and return their sum as an int) and an object - a receiver to call the method on) a method invocation is finally first class citizen in the [[VM]]. One can do [[wikipedia:Currying|currying]] & co. - all the goodies functional languages had for ages.

What is a [[MethodHandle]]? A pointer to method of some signature (for example ''plus'' would take two ints and return their sum as an int) and an object - a receiver to call the method on. However this is nothing else than a [[closures|closure]] - hence the idea to use it to implement '''lambdas'''. But there is a hidden catch...

But there is a hidden catch...

=== Getting Dynamic ===

=== Getting Dynamic ===

=== Getting Dynamic ===

=== Getting Dynamic ===

The primary goal of John R. was to support dynamic languages - e.g. languages where one knows (almost) no type information until the program actually runs. That means one can effectively type (in this [[JVM]] context: effectively generate [[bytecode]]) only when one knows the actual types. To address all these "deffered" needs the new [[invokeDynamic]] [[bytecode]] operand had been introduced. It does not hardcode the actual invocation, but once invoked, it calls back to let the "supervising" software (like your [[JRuby]] implementation) to analyse the actual call parameters and generate sequence of [[MethodHandle]] transformation (possibly a bit of [[wikipedia:currying|currying]], mostly type conversions) to effectively match the actual types of method arguments.

The primary goal of John Rose was to support dynamic languages - e.g. languages where one knows (almost) no type information until the program actually runs. That means one can effectively type (in this [[JVM]] context: effectively generate [[bytecode]]) only when one knows the actual types. To address all these "deffered" needs the new [[invokeDynamic]] [[bytecode]] operand had been introduced. It does not hardcode the actual invocation, but once invoked, it calls back to let the "supervising" software (like your [[JRuby]] implementation) to analyse the actual call parameters and generate sequence of [[MethodHandle]] transformation (possibly a bit of [[wikipedia:currying|currying]], mostly type conversions) to effectively match the actual types of method arguments.

=== Drawbacks ===

=== Drawbacks ===

[[Java]] and [[JVM]] needs to get smaller (to compete with emerging and improving competitive technologies; think of [[V8]] and [[NodeJS]]), not bigger. Complicating them just makes it harder to port [[Java]] to new, small areas of use.

[[Java]] and [[JVM]] needs to get smaller (to compete with emerging and improving competitive technologies; think of [[V8]] and [[NodeJS]]), not bigger. Complicating them just makes it harder to port [[Java]] to new, small areas of use.

Should not we rather think twice before repeating the [[invokeDynamic]] failure [[Value classes|again]]? Should not we fix the issue - for example by removing/deprecating [[invokeDynamic]] from future [[JVM]] spec and replacing it with '''newFromAMethod''' [[bytecode]]?

Should not we rather think twice before repeating the [[invokeDynamic]] failure [[Value classes|again]]? Should not we fix the [[invokeDynamic]]/[[Closures|lamda]] issue - for example by removing/deprecating [[invokeDynamic]] from future [[JVM]] spec and replacing it with '''newFromAMethod''' [[bytecode]]?