Inlining closure

I did some manual experiments of inlining the body of closure from the previous post to make it fast. So far the inlining technique would work only for anonymous closures as it won't be referred by other codes.

For example, if a$a is an anonymous closure:

DefaultMethods.times(100, a$a);

can be inlined as the private method inlined_DefaultMethods_times:

inlined_DefaultMethods_times(100);

Then the body of DefaultMethods#times will be copied to construct the above private method. After that the callsite of Closure a$a will be replaced with its body, the method a$a__0.

The original DefaultMethods#times:

public static void times(int num, Closure closure) {
for(int i=0;i<num;i++) {
closure.call(i);
}
}

The inlined method inlined_DefaultMethod_times:

private void inlined_DefaultMethod_times(int num) {
for(int i=0;i<num;i++) {
a$a__0(i);
}
}

The result is reallly impressive, 22 sec, which is comparable to original Java code.

Steps toward encoding fast closures, reflection-based closure

With the reflection-based closure approach from last post, I've got some codes to compare performance.

The following is a Groovy code,

class TestGen_002 {
def a = {
1000000.times {
println it
}
}
}

And this is the manually translated code. Class TestGen_002 contains reflection-based closures, a and an anonymous closure for times.

package org.codehaus.qdg;

import org.codehaus.groovy.qdg.Closure;
import org.codehaus.qdg.runtime.DefaultMethods;

public class TestGen_002 {

public Closure a = new Closure(this, "a__0");

private Object a__0(Object... args) {
Closure a$a = new Closure(this, "a$a__0");
DefaultMethods.times(1000000, a$a);
return null;
}

private Object a$a__0(Object... args) {
System.out.println(args[0]);
return null;
}

}

Although it's fast, 28 secs, compared with traditional Java for loop (22 secs). I've been trying to get its speed closer to Java.

Implementing Closure without using inner classes

This implementation is inspired from Charles Nutters' discussion about his experiences implementing JRuby. I didn't have much time to look into it, until now. So here's my first implementation of it.

I have my Closure field a, and its body a_body.
In the Closure class, the ctor will reflectively get the declared method "a_body" by name.
When you'd like to invoke the closure, just call a.call(). Then it will normally invoke the "a_body" method with reflection.

package org.codehaus.qdg;

import org.codehaus.groovy.qdg.Closure;

public class TestGen_001 {

public Closure a = new Closure(this, "a_body");

private Object a_body(Object... args) {
System.out.println(args[0]);
System.out.println("a_body");
return null;
}

}

And here's a simple implementation of the class Closure:

package org.codehaus.groovy.qdg;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.security.AccessController;
import java.security.PrivilegedAction;

public class Closure {

private Object target;
private Method method;

public Closure(Object target, String methodName) {
this.target = target;
try {
method = target.getClass().getDeclaredMethod(
methodName, new Class[]{Object[].class});
AccessController.doPrivileged(
new PrivilegedAction(){
@Override
public Object run() {
method.setAccessible(true);
return null;
}
});
} catch (SecurityException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
}
}

public Object call(Object... args) {
try {
return method.invoke(target, (Object)args);
} catch (IllegalArgumentException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}
return null;
}
}

A closure body, which is a private method, is accessible by setting Method#setAccessible(true).

Quasi Dynamic Groovy

I'm trying to summarise what I want from Groovy.
One of my goal is to use Groovy for numerical computing. I love Groovy syntax because it's concise, compact, and elegance when writing an algorithm. So I've started writing code generator from Groovy parser. It's relatively easy to start, if you have .jar distribution of Groovy.

Here's a list of my requirements:
- Partially static Groovy
- AOP support by design, at the level of the runtime system.

Challenges so far are:
1. Is it possible to make a Groovy class partially static? IMO, I think it would. The support reason is very obvious. Now, we can mix Groovy and Java classes in the same system.
So what if we resolve method references at compile-time. If the method reference is found we make it static, if not we just make it dynamic.
2. Is it possible to use the envelope technique to wrap around method calls, getters, setters, etc.
This technique can be used to have a dynamic AOP support.
3. How to keep the class semantic to be as similar as possible to the classic Groovy.

Groovy AOP - Part #4, Getter and Setter PCDs

I haven't implemented pointcut designators (PCDs) for getter and setter because I actually forgot about them.

I recall them this morning, and really see the advantage of using them for Grails domain classes. I think using it can definitely solve the problem's been caused by Hibernate setter issue. Here's the situation.

I have the domain class, User containing the password field passwd:

class User {
...
String passwd
}

What I wanted to do is to store MD5ed password by just calling new User(password:'abc').save(). But this won't work. It's the Hibernate limitation that does not allow me to have the setter for passwd, say setPasswd, because the setter will be called, at least, twice when Hibernate 1. initialises the object, 2. sets the value into the property. Yes, I got my password hashed twice !

So here can be a solution (I have to try it first to confirm this anyway).

Groovy AOP can provide a shortcut for getter and setter like:

class User {
static aspect = {
before(set:'passwd'){ value -> value = MD5(value) }
}
...
String passwd

}

Why this's going to work? I think it works because Groovy AOP works at meta-layer, while Hibernate works at bytecode (proxied) layer. It's possible for Hibernate to set the property directly (as it does not invoke the call through Groovy invoker). Good use case?

Groovy AOP - Redesign #3, Advise By Convention

This idea came solely from seeing what Grails's using for interception.
The idea is simple, like ActiveRecord pattern used in Grails (e.g., find*)

In Grails, users'd like to have before, after interceptions for their controllers, domain classes, etc.

Like this:

class MyController {
static beforeInterceptor = ['*', this.&auth]
}

and this:

class MyDomain {
String field1

static beforeUpdate = {
}

}

So Groovy AOP would support these kind of functionalities with conventions in its aspect language like the following for controllers:

MyController {
static aspect {
beforeAll { println 'test' } // = before(call:'*') { }
beforeUpdate { println 'test' } // = before(call:'update') {}
}
}

and following for domain class dynamic methods:

MyDomain {
static aspect = {
beforeSave { }
beforeUpdate { }
afterUpdate { }
afterSave { }
beforeNew {}
}
}

To sum up here, what Groovy AOP should support in its aspect language are before*, after*, and around* to simplify the use of AOP in practice.

Groovy AOP - Redesigned #2

OK, I'm now continuing to show that what've I made changes to the syntax of Groovy AOP.
Last post, I've showed the new syntax, and there's a few more tweaks here.

In the trunk, now we can have aspect like this:

class MyClass {
static aspect = {
before(call:'update1') { println 'before update 1 ..'}
after(call:'update2') { println 'after update 2 ..' }
}
}

and this:

class MyClass {
static aspect = {
before('update1') { println 'before update 1 ..'}
after('update2') { println 'after update 2 ..' }
}
}

Both have the same semantic. They read, before the call of (join point of) MyClass#update1, do ..., and after the call of (join point of) MyClass#update2 do ...
I think these shortcuts will be comfortable enough for people to use without AOP knowledge.

The implementation's also changed internally to override MetaClassImpl#invokeMissingMethod rather than MetaClassImpl#invokeMethod.

Groovy AOP - Aspect Builder Redesign #1

I've just got Groovy AOP running first time with Groovy 1.1, and seriously I'm looking to integrate it with Grails when its 1.0 debuts. My problem now is still the classic AOP problem, how could we have an expressive and easy pointcut language for people?

I know that advantages of Groovy AOP to Grails are quite clear, but if and only if developers uses it. So I'm trying to re-design the pointcut language before getting 0.3 out.

class MyController {
static aspect = {
before(call:'*') { println 'something' }
before(withIn:'') { }
around(call:'update*') { inv ->
println 'before'
inv.proceed(inv.args)
println 'after'
}
def pc = call('update*') & within('main')
around(pc) { inv ->
println 'before'
inv.proceed(inv.args)
println 'after'
}
}

def update() {
}

def update2() {
}
}

Above is how we can embed "aspect" into Grails controller. I intend to leave the "static aspect" block to say that "hey, you're using AOP here". Don't know if people will have objection to this.

The shortest code we can use to have "before interceptor" for every method in the class is:

static aspect {
before(call:'*') { println 'before' }
}

Tomorrow, I'll continue with next thought about this.