 Good afternoon everybody. Myself Nadeesh. I work for Java SQL team at Oracle and today I am going to talk about invoke dynamic, which is a new bytecode introduced in Java server. In this talk, basically I am going to cover, basically answer three questions. Why invoke dynamic? What features it is provided and how it is provided? If you have any question you can ask in between itself. Don't wait till end because if you lost something in between I think you lost the entire time. I mean audible. JVM languages are languages which you can run on top of Java virtual machine. And to run a language on JVM, we have to produce a properly valid classifier which contain bytecodes. And there are 200 plus JVM languages. And Java is the primary language which run on top of JVM. There are other languages like JRuby, Jython, JavaScript, Groovy, Smalltalk. Most whatever language you name it will be it will have JVM equivalent version. The problem with this thing is basically JVM is designed primarily for Java and there is a tight coupling between Java and JVM semantics. But semantics of other JVM languages, take example Python. Its semantics is completely different from Java. For example Python is a dynamically typed language but whereas Java is a statically typed language. Dynamic type in one diamond is this is a Python code where you can this is a function which I define. Here this function will take two arguments but contrary to Java, here we are not defining any type. And the variable will assign the type at runtime. If you are passing some integer to some, then A and B will assign to the type at the runtime. If you pass float, it will be float type. And basically that's basically dynamic type. At runtime you will get the type. Then other semantic differences, method invocation can be different in semantics of method invocation can be different in other dynamic languages. For example Smalltalk uses kind of a message passing mechanism for method invocation. In other languages you can add functions at runtime. This is not possible in Java. Then another difference is scope access rule can be different from Java. For example Java you have a public private protected default kind of access rules but other languages may or may not have. Therefore what I want to say is to run a non-Java language on JVM it has to go via wrapper or simulation. This wrapper layer has to simulate the non-Java languages execution on JVM. The problem with this wrapper layer is this wrapper layer can cause performance overheads while running JVM. The performance overheads what I meant is this non-Java implement is they have to write lot of extra code to make it work or make it run on JVM. Lot of code means lot of byte codes. If you have a lot of byte codes JVM have to load lot of code. It's a performance overhead. Then another pain points of this wrapper layer is most of the dynamic languages use reflection. The disadvantages of reflection is if you are invoking a method using reflection for example some method.invoke and if you are passing some arguments to that the problem with reflection is every invocation use access check. Because you can call a method from anywhere you have to check whether at this point this class is allowed to call that method or not. Because of that point in reflection that access check is mandatory for every invocation. Then second point is in reflection the method argument basically that method.invoke will accept object as an argument. Even though your final method will accept primitive the reflection method.invoke is accepting object. Therefore we have to do a lot of boxing and in then we have to do a lot of unboxing. Therefore there will be some there will be n number of unused objects just for to match this reflection semantics and it needs to be garbage collected. This is another overhead. The third and most important overhead is this wrapper layer act as a black box for the JVM. For example just see this method. This method accept a Boolean and based on its true or false it is running it is branches out and if you are always passing a false ideal case should be I mean it should inline this thing and it should remove the else loop. But problem with this wrapper layer is this wrapper layer may contain multiple layers. Before reaching into the JVM call this particular call in the non-jamal languages may have to go through two three layers because of this thing. This may not be kind of transparent to JVM. Therefore this thing can act. This thing can act. I am not telling it will act. It can act as a black box and it will affect inlining. Inlining if it is effectively inlining means it is affecting the performance. Basically inlining is considered as the mother of all optimization which affect inlining means it affect performance. Therefore what I want to convey is to run a non-jamal language call it as a dynamic language to run non-JVM it has to go via wrapper layer. This wrapper layer causes performance overheads due to multiple reasons. Now we will see what are the byte codes supported for method invocation in Java before Java 7. There are four byte codes were there before Java 7. First one is called invoke static. It is used to call static method. For example if you have a static method and if you are calling using a class A dot static method the equivalent byte code of the above invocation will be invoke static and it will point to some constant pool of the class web. If it is a virtual method, virtual method I mean instance method and if you are calling that instance method using an object the equivalent byte code invocation will be invoke virtual and it will point to some constant pool of the class. The third method, third thing is if you are calling a method using an interface reference for example list l equal to new array list and you are calling the add method using l is a interface reference. If you are calling a method using the interface reference the equivalent byte code invocation will be invoke interface. Then the fourth one is invoke special. It is used to call private methods, constructors and all method, all super dot method. If you are calling a method using super dot or a very equivalent byte code invocation will be some kind of invoke special and it will point to the constant pool. That five is a point index to the constant pool of the class web. If you check the class web before starting the code there will be a tabular thing called constant pool and this index will be a point to that constant. Now we will see whether all these existing byte code can match the requirement of a dynamic language. Before going further we had to note two terminologies. One is called a receiver. In oops terminology, receiver means object and second terminology is dispatch. Dispatch basically means at runtime search the method and link it to the call site. Now we will go through one by one for each instruction. For invoke static you don't need a receiver because in oops terminology receiver means object and static method doesn't have any object associated with. Therefore you don't need a receiver for invoke static and dispatch also for invoke static you don't need any dispatch. Why? Because at compile time itself it means that at compile time itself the compiler knows that which static method it has to go. It's not dynamic. All static methods are if you see the all static methods are compile time itself compiler now which it has to go. Therefore there is no need of a dispatch and second is invoke virtual. Invoke virtual is an instance. Invoke virtual is a byte code for calling instance method. Therefore it need a receiver. The object will be the receiver and it need a dispatching logic because because because for the using polymorphism and all using method table or virtual table it have to search which method you have to call and overloading is possible. Therefore invoke virtual you need a dispatching logic and same in the case with invoke interface. You need a receiver for invoke interface and the same logic dispatching also because it's possible for overloading and all. Therefore we have to go via method table or v table to search the method. And the fourth one is called invoke special which we used to call private method or super or constructor. For invoke special also we have a receiver because and there is no dispatching logic because it's again private method constructor everything is determined at the compile time there is no overloading happening. Therefore you don't need a dispatching logic for invoke special. Now the problem with the dynamic languages, dynamic languages may or may not have a receiver. I mean some languages doesn't have the concept of object orientation itself. Therefore they don't have receiver. Since they don't have the receiver they may or may not have the dispatching logic. Therefore our existing byte codes will not fit for the dynamic languages. Therefore this dynamic language, compiler, implementers have to do some work around to work on JVM. And basically this work around or this work around will be simulation cost, performance overhead for the non Java languages to run on JVM. Before going further details I can take questions if you have. Whether the receiver dispatched concept is understood and why invoke dynamic was really required. What was the shortcomings of the existing byte codes? Okay. Two, since existing byte codes have short time shortcomings. This in 2005 the OpenJDK started new project as part of a DaVinci machine project. There is a project for all the new, there is a project called DaVinci machine project is basically started for creating basically creating new language level features. The project aims to introduce new language level features. It started in 2005. It started as a JSR 292 to support dynamically type languages. And it completed in 2011 and it released as part of JDK 7. The two key features of this JSR 292 was it introduced a new byte code called invoke dynamic. And apart from this it introduced a new unit of behavior called method handling. And in the rest of the talk we will go details about both invoke dynamic and method handling. In work dynamic it's a five byte instruction. The first byte will be an opcode and second and third byte will be a index to the constant pool as usually we as we saw in other invoke codes. The second and third byte will be a index to a constant pool. The fourth and fifth byte are currently unused. It's kind of kept for a futuristic purpose. And the key features of invoke dynamic is it doesn't require any receiver. And it can have a custom dispatching under user control. And it can be re-linked dynamically. I will go through what it really means later. But the first two things are the important ones. It doesn't require any receiver and it have a custom dispatching and that too under user control. Rest all the method doesn't have a custom dispatching and whatever dispatching was happening it was happening under JVM control not user control. In work dynamic it will happen at user control. Now we will go through why, okay. Now we will go through how invoke dynamic is really happening. In your dynamic language if you have a method called foo and it accept one in argument and a string argument. For example in Python if you have a code like foo one of string A the equivalent byte code instruction will be invoke dynamic and there will be a pointer to a method called bootstrap method and then foo and the arguments whichever you pass. This point is called a dynamic call site. I mean the point where the method invocation happened is called dynamic call site and the equivalent representation of that code in byte code will be in this format. In work dynamic then it will point a second thing will be a pointer to a bootstrap method and method name and the argument which you passed at the process of bootstrapping means linking this dynamic call site to a method. That process name is called bootstrapping and it's a one time activity. That is the important thing you have to notice. It's a one time activity. It will link to a method only one time. As long as you are not changing the method you can change the argument. As long as the method argument types are not changing the re-linking will not happening and the bootstrapping will happen only one time. Now this invoke dynamic instruction call site will call a method called bootstrap method. This I will go in detail what is a bootstrap method but this bootstrap method will return in a call site. The call site contains a method handle. I will go in the coming slides I will explain what is meant by method handle and basically invoke dynamic will call a bootstrap method. Bootstrap method will return in a call site. The call site will contains a method handle. This method handle will have method handle is equivalent to a pointer to a method. Therefore, after resolving the invoke dynamic instruction you will get a method pointer at that place. That is the ultimate purpose of this thing. Any questions? Most of the dynamic languages the type is determined at the runtime. So how do you do the typing here? My question is how do you determine the type? For example, it can be integer or it can be long. How do you convert it at runtime? At runtime whatever argument you are passing it will directly go to it will directly come here. It comes here and we do not know the type. This is a runtime. This thing is happening at runtime. Your equivalent for example python have a call called foo of one A. That means you have the type you passed the type at that time. It is a call site. It is not the method definition site. If it is a method definition for example foo A, B it does not have the type. This is the call site. You are calling foo with 1, string 2. That means you have the type. Because in some dynamic languages for example it can be an integer or it can be long based on the number that is passed. So which method gets called in that suppose I have two methods. One which takes an integer as an argument and the other takes as a long. From my dynamic language I pass a value some number. It can be either an integer or a long. How does it determine? That will happen in bootstrap method. The bootstrap method will contain the logic. How will you determine that method? I will come in the coming slides. The bootstrap method is a method which will take minimum three arguments. First argument is called lookup. In the coming slide I will say what is lookup. The second argument is a string argument. You can pass any value to this string. It can be a method name or it can be anything. JVM spec does not enforce you to JVM spec does not tell you what it should be. But it should be a string. According to your implementation logic you can pass whatever if you are. Most of the dynamic language will pass method name in string. The third one is called method type. This is the method type of the call sign. For example you are in our earlier example we have a foo. Assume its return type is void and it is taking an integer argument and a string argument. Therefore you have to pass this method void. You have to pass in this format. Return type followed by the argument type. Therefore you have to pass a method type object which will be basically a void followed by in commas. You understood in your quick you got flat field because whatever type you pass at the runtime that type will pass to this bootstrap method. Now it is the byte code generators basically the dynamic languages convey less responsibility to you. Link your invoke dynamic instruction to appropriate bootstrap method. Dynamic language implementers have to link whenever they see a dynamic code they have to link it to the appropriate bootstrap method. It is their responsibility. It is not the user responsibility. Now another thing which we have to notice here is you can see invoke dynamic instruction. As usual JVM will try to resolve those things at JVM level. Since it is an invoke dynamic instruction since it is special what JVM will do is JVM will do an up code to the user level method. Basically whenever a code happening from a JVM to a user level that basically technically it is termed as an up code. Whenever invoke dynamic instruction sees JVM will do an up code to a bootstrap method. The important thing about bootstrap method is this method is defined by the user. Therefore the resolution further resolution logic will happen in bootstrap method. Therefore the resolution in then you can see that it is happening under user control. Did I really get mark, this slide really want to say. In the normal case every invoke method will resolve at JVM level. For example assume that it is an instance method. It will be a basically invoke virtual some foo 1 comma 2. Then what JVM actually do is associated with every object there will be a virtual table or method table. JVM will go and search in the method table where this method is defined. Then it will get the pointer for that method. It will load the method and it will try to execute it. Here what will happen is when it see invoke dynamic instruction it will do from the JVM itself. They will have a code back to the user level. They will call the bootstrap method and tell basically it will tell bootstrap that I mean I don't know how to link it. You please link it. And then basically linking is happening at user control. Now we will see an example. It is a lambda expression for random. Lambda expression is the only thing which can produce a invoke dynamic using Java language. There is no other expression in Java language which can produce a invoke dynamic instruction. Because basically it evolved for a dynamic language and there are some other byte code generating tool which using which you can generate a invoke dynamic. And in Java 7, Java as such if you compile any Java program it will cannot generate any invoke dynamic. In Java 8 when they introduce lambda lambda will produce if you compile a lambda expression you can see invoke dynamic. Now if you combine if you see the byte code I am just putting the relevant byte codes for this equivalent expression. If you see the byte code of this particular statement it will be a you just check the in your constant pool section. It will invoke dynamic and first argument as usually it will be a boot. It will point a bootstrap thing. The second will be the name and type like our foo and 1, 2. The second will point to a name and type. It will be basically the method name and type. The first one will be a bootstrap method. It will point to a area in the constant pool itself called bootstrap methods. And this will point to the original bootstrap method. For lambda it is the bootstrap method is this one. It is a static method. It is called meta factory. It is there in the lambda meta factory class. Everybody understood the flow. If there is a lambda expression in this way it will equally convert into this form. Invoke dynamic, some index, another index. The first index will be a point to a bootstrap method. This bootstrap in then it will finally solve it to a static method. That static method is lambda meta factory dot meta factory. Then second arguments are the name and type in foo, 1, 2. That name and type will resolve to runable. Since it is a runable it will resolve to run and runable. This is the example any classification is required. I talked here and there about some term called method handling. We will see what really mean by a method handling. Method handling is basically a point even though the names are just method means it can point to method constructors and field. Basically you can consider it as a function point. Basically it is a pointer equivalent of C++. Method handling is a pointer equivalent of C++ which can point to methods, constructors and fields. Now we will see why what is this method handling. Before going further details about method handling we saw here that every bootstrap method first argument will be a lookup object. You will see what it really mean lookup object. Lookup object is an object which contains the access permission. It will get clear when I am showing an example. The lookup object is used to create a method handling and there are two kinds of lookup object. One is public which will have the public access. Another one is called normal lookup which will have the public access and private access. By an example you will understand it. I know from the phrases you did not understand but I will show you an example and we will see. This is the way you are creating a method handling. First you have to call a method handles dot public lookup. Basically assume that you want to call value of method in the string class. We will see how we can call it using method handling. Since value of is a public class you can create a public lookup using method handles dot public lookup. It will create a lookup. Then value of is a static method. Therefore you have to call a lookup dot find static. If it is an instance method you should call find virtual. If it is a private method you should call find special. In all the equivalent logic you can find here also. Since it is a static method you have to call lookup.find static. You are searching the value of method in string.class. Therefore you have to specify the class name for string.class. Then the method name value of. Then you have to specify the type. This value of will take care as an argument and it will return string. Therefore you have to specify the method type in this way. First you have to specify the return type. Then you have to specify the argument. Now once you have a method handle you can call the method using basically two methods. Here I use invoke excite. You can call method handle dot invoke excite and you can pass the argument. This thing is equivalent to calling a string dot value of and passing. This thing is quite clear. Basically method handle is a function or field pointer and you can use those things to invoke here. What is OK? Java as a language or JVM as a platform do not provide as such and what this invoke dynamic and its related semantics is able to make that linkage possible. I think discussion on that front will really help. Yeah, that's OK. I think I covered that thing already. First one thing was the existing byte codes require some receiver and dispatching logic. The dispatching logic was entirely under JVM control. Understood? Since you are getting the type at runtime ideally assume that there is no invoke dynamic and if you are calling a foo of 1,2 in dynamic language as a implementer the name way which I can assume is foo is a method which will take two argument. Then I will have a switch case. If the first argument is in called foo which will take an int. If the second argument is string I mean you understood now. That is the name way of implementing it. First of all are we talking about intra language invocation or let's take an example of a Ruby. Are we talking about a Ruby method invoking another Ruby method or a Java method invoking a Ruby method? A Ruby method invoking a Ruby method but that Ruby will run on top of JVM. Understood? You will write a Ruby code only but it's not the normal Ruby, it's called JRuby. There you can access the Java libraries and Java packages. Basically a Ruby code which is converted to Java byte code and attempting to invoke another Ruby method which is again converted to Java byte codes. Is the fact that today you have a lot of different languages Kotlin, Ruby, whatever. Some of these can run on JVM. How is it possible or how is it made to run in a more efficient manner is what he is trying to tell by invoke dynamic. Any other question? Then we will continue the discussion about method hands. Method handle is used to invoke, a method handle is in then it's kind of a function pointer using which you can call methods and this is the way of one way of calling it and there are actually two way of calling it. First one is called invoke excite and second one is called invoke or invoke generate. Invoke excite means the type should match exactly. If the value of, okay, assume that there is another method which will take integer object and if you are passing int and if you are trying to do a invoke excite on that method it will throw a wrong method. If it's invoke excite the type should match exactly and if it's invoke this kind of type mismatch is allowed. Basically they can do boxing, unboxing and cast and for example if you are calling a method which talk integer and if you are passing an int and if you are calling a method.invoke it will work because it will box it and cast it and if that also not working it will throw a wrong method type exception. Now what I want to, okay, okay, now I will see the importance of lookup. I will, I just mentioned the lookup I didn't clearly specify what it really meant. For example check a class B which can take a private method which have a private method and there is another class A and you are trying to create a method handle of private method of B. There is a private method in A you are trying to create a method handle for private method of B. If you write this code it will throw a illegal access exception. Why it's throwing illegal access exception is because you don't have the permission of calling a private method of B from A. Why it's happening is if you call a method handles.lookup what it will give you? It will give you a and okay if you call a method handles.lookup that lookup object will not have the access to call the private methods of B because only B will have the access to call the private methods of B. Okay, therefore you try to do a lookup for a private method here it will throw illegal access exception. Is it clear why lookup is important? Yeah, yeah, yeah, exactly, yeah you can do that. See for example if I have a public method, for example if I have public field called lookup and in B the first statement is public lookup equal to method handle.lookup and then in A you can do a.lookup and you can call the private methods of B. Therefore it's the responsibility of the individual class to share the lookup object or method handle to trusted partners. Is it clear why lookup what's happening with lookup, what will not happen with lookup. Now we'll go if you go back to our earlier flow. There was a dynamic call set. That dynamic call set was okay I think my time is almost out there for I'll quickly go with it. There was a dynamic call set. That dynamic call set was calling a bootstrap method. This bootstrap method will take three arguments one is lookup another thing some string and another thing method type and since now you understood that if you have a lookup and you know the type and the name of the method you can create a method handle out of it. Okay. Therefore in the bootstrap method you will have a logic based on the because now the thing you'll get interesting. Now everything is happening at the run time. At run time you will get the type maybe even it's a dynamic language at run time you will get the type. That type will pass to the bootstrap method then JVM will pass the lookup object to that bootstrap method. Since JVM is passing you the lookup object JVM know whether the current context have the access permission or not. Is it clear? Since if you okay now if you get the lookup and the method type and you know the name you can create a method handle out of it and you can just return the method handle and using this method handle you can call it. Understood? That's the high level flow. Now why okay we'll see the advantage of it. One important thing is in reflection what we see is every time you are invoking it will it was going via access check because reflection is like that. I mean you can call a method from anywhere and therefore access check is necessary. Okay now in method handle this access check will happen only during the creation because using lookup it will check the access check and it will say whether do you have the right to create a method handle. If you have the right to create a method handle you will create it. Now since once you create a method handle you don't need for no more access check is required. Because if you can create a method handle means you have the access. Once you have the access you don't need to waste time on again doing an access check. That's the one of the advantage of method handle. Second thing is signature polymorphism since I can see so many confused face and not completely going what is signature polymorphism. Basically what it will do is if you have a if your method is signature polymorphic method how you can make a method signature polymorphic. In Java 7 they introduce a new annotation called polymorphic signature. It's kind of private thing your normal user can't use the only it's allowed only in the Java dot length packages Java libraries basically. If the method is a signature polymorphic method then what will happen is see for example assume that the method is not a signature polymorphic method and invoke excite is a normal method which take a var acts of object. Then if you are doing a call here the type if you check the type it will be basically an integer and string. Now if it's a normal method invoke excite is accepting a array of objects and you are passing a int and string basically what it will do? It will do a boxing and it will try to call them. This is the normal case. If the method is polymorphic signature if the method is annotated with this one what it will do is it will not do the boxing. It will just whatever argument it's getting it will just pass through it. And as long as our method handle is pointing to a method which accept an int which accept an int and string it will work as well. By this way I mean you don't have to do no more boxing and boxing and it reduce because of this thing. Otherwise if you are doing a lot of boxing and boxing there will be so many garbage collectable object lying around there just for this conversion. Since the method is polymorphic signature polymorphic compiler knows that I mean basically compiler assume that in the while executing JVM will take care of this thing. I don't have to mind about it. I mean whatever object I am getting I will just pass through it. In the end if the method handle is not pointing to the right method just throw an excite. No no. Yeah exactly but one slight difference is that first it will try to do a excite match. If it's a invoke first it will try to invoke an excite match. If that excite match is not happening then only it will do a boxing and boxing. Therefore even if you are using invoke and the method you are passing is a correct method the no need of boxing understood. As long as you can do a invoke excite using invoke you are fine with it. This is other casting understood now. If in the worst case you can't do a casting and uncasting if it's a invoke it will do the boxing and boxing. Invoke excite will never do that. Therefore it depends upon you if you are okay with the invoke you can do it otherwise if you want invoke excite you can do it. And final thing is call site. Basically if you check the flow it was something like this invoke there is a dynamic call site it will call a bootstrap method. Bootstrap method will returns an object called call site. Call site contains basically method handle okay. And we covered almost all of it no only thing that is call site. What call site is really do is basically call site is a wrapper object for method handle. Call site will have field called target and this target will contain the method handle. And the advantage of the call site is assume that you are calling some hundred times method foo with integer and string. And in the one note one note one time you decided that no instead of int I will call a string string okay. At that time what will really happen is it will not go through the bootstrapping process instead of that in what it will do is it will create a method it will try to create a method handle for a string string and in the call site it will just change the target. Roughly maybe I know it's kind of confusing but basically since bootstrapping is a heavy process that thing will happen only once and if you need to really link to a different method at the end time you have to just change the call site target. You don't have to go via bootstrapping. Now another advantage of call site is once you resolved an invoked dynamic and if you check the method table basically this is the way usually a method instruction is executed. It will check the okay it will see it's a method instruction then it will go into the constant pull cache entry and it will check whether this instruction is already linked to a method or not. If it's linked it will use it from there. If it not then it will try to resolve it and put it there. Since once you know get the call site you can put the call site in that constant pull table. Once it is there it's entirely under a jit control. As long as the call site is not changing jit can go do an inlining optimization. It's something like 100 times it calls the same method in with string. Then instead of putting a call site there what it will do is it directly inline the method here and directly go it. It's kind of basically what it is doing is this call site is kind of basically transparent to jit and it can do the optimization better than if a wrapper layer is there. And this is the end actually. This is the summary. There will be a dynamic call site. This dynamic call site will call a bootstrapping method. We have to pass lookup and method type to this bootstrap method. And this bootstrap method will return a call site which containing method help. And these things internally solve all the problems of reflection which we talked earlier. Every invocation doesn't require any access to it. Method argument doesn't need any boxing or unboxing as long as you are in working with the correct type. And third thing is it's not a black box to jvm anymore. Call site is transparent to jvm and it can do the inlining as long as it can do the optimization. I can see a lot of the confusing things. Since it's a hard topic I know it's assumed that it will be that. Yeah. Yeah. Yeah. Yeah. It will create a new method help. At that time again the access check will happen. Access check is happening at the creation of the method handling. If you have the access you are able to create it and you can call. Any more questions?