Groovy explores--call site analysis

Groovy 1.6 introduces call site optimization. Call site optimization is actually the cache of method selection.

Method selection

In a static language (such as Java), the binding of a method call is done at compile time (not exactly, such as a virtual function, but in general, the method invocation of a static language is very efficient). In a dynamic language such as groovy, the method invoked is selected at run time. This is one of the important reasons why dynamic languages are slower than static languages.

For example, to invoke "A.call (1)".

If it is Java, in the compilation period will choose a good call method, in this example, the class of the object declaration is selected (note that it is not the real class of object A, because the real class is to be known at runtime), the name is call, there is a parameter, the parameter type is int (the actual situation is much more complicated , such as also consider boxing and variable parameters, etc., if you cannot find the compilation does not pass, otherwise the method binding. Disassembly of this method calls can be seen as "invokevirtual #4; Methods call: (I) V "The instruction, which indicates that the method is bound, includes the method name" call ", the parameter type" I "(int), and the return value" V "(void).

If it's groovy, it's all done by groovy runtime, and groovy does not check to see if there is a way to match the call when it compiles the code. When you compile with Groovy 1.5.7 and then decompile to Java code, you can see "Scriptbytecodeadapter.invokemethodn" (Class1, A, "call", new object[) {New Integer (1)}), which shows that groovy does not really have the option of invoking the method at compile time, but rather to the run-time decision.

Call Site

According to the Wikipedia definition (http://en.wikipedia.org/wiki/Call_site), call site is a one-line method invocation, such as:

a　=　sqr(b);
c　=　sqr(b);

is two call Site.

Call site Optimization

Before groovy 1.6, calling the method n times for the same call site would take N-time method selections, such as:

for　(i　in　1..3)　{
a.call(i)
}

For (i in 1..3) {
a.call (i)
}

Here, groovy chooses the call Method 3 times, even though the results of the 3 selections are the same.

The call site optimization introduced in Groovy 1.6 caches the method selection results of the same call site, and if the next invocation is the same as the parameter type, the cached method is invoked, or it is selected again. This is the basic idea of call site optimization.

Code Analysis

Consider the following groovy code:

class　A　{
def　a()　{}
def　b()　{}
def　b(int　i)　{}
}

class　B　{
def　a　=　new　A()
def　c()　{
a.a()
d()
}
def　d()　{
a.a()
a.b()
a.b(1)
}
}