InvokeDynamic - Revision history

JaroslavTulach at 07:11, 5 May 2015

JaroslavTulach — Tue, 05 May 2015 07:11:11 GMT

←Older revision		Revision as of 07:11, 5 May 2015
Line 27:		Line 27:
	=== 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]]!

Cordeo: "loss of types" instead of "loose of types"

Cordeo — Mon, 08 Dec 2014 09:23:57 GMT

"loss of types" instead of "loose of types"

←Older revision		Revision as of 09:23, 8 December 2014
Line 21:		Line 21:
	=== 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.

JaroslavTulach: /* Diverging Future */

JaroslavTulach — Thu, 25 Sep 2014 12:58:04 GMT

Diverging Future

←Older revision		Revision as of 12:58, 25 September 2014
Line 76:		Line 76:
	[[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]]?

JaroslavTulach: /* Extra Syntax on Top of Existing One */

JaroslavTulach — Thu, 25 Sep 2014 12:56:46 GMT

Extra Syntax on Top of Existing One

←Older revision		Revision as of 12:56, 25 September 2014
Line 66:		Line 66:
	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 ===

JaroslavTulach: /* Solution for the JVM */

JaroslavTulach — Thu, 25 Sep 2014 12:54:02 GMT

Solution for the JVM

←Older revision		Revision as of 12:54, 25 September 2014
Line 46:		Line 46:
	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.

JaroslavTulach: /* Getting Dynamic */

JaroslavTulach — Thu, 25 Sep 2014 12:44:38 GMT

Getting Dynamic

←Older revision		Revision as of 12:44, 25 September 2014
Line 9:		Line 9:
	=== 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 ===

JaroslavTulach: /* Benefits */

JaroslavTulach — Thu, 25 Sep 2014 12:43:47 GMT

Benefits

←Older revision		Revision as of 12:43, 25 September 2014
Line 3:		Line 3:
	=== 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...

JaroslavTulach: /* Benefits */

JaroslavTulach — Thu, 25 Sep 2014 12:43:15 GMT

Benefits

←Older revision		Revision as of 12:43, 25 September 2014
Line 3:		Line 3:
	=== 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 ===

JaroslavTulach: /* Getting Dynamic */

JaroslavTulach — Mon, 15 Sep 2014 06:46:21 GMT

Getting Dynamic

←Older revision		Revision as of 06:46, 15 September 2014
Line 9:		Line 9:
	=== 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 ===

JaroslavTulach: /* Diverging Future */

JaroslavTulach — Sun, 14 Sep 2014 19:35:10 GMT

Diverging Future

←Older revision		Revision as of 19:35, 14 September 2014
Line 76:		Line 76:
	[[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]]?