Torsten Curdt’s weblog

A while ago I read about the so called “Duff device”. You use it to reduce the counting overhead of loops and to get a better performance when copying memory around. Well, have a look at this valid(!!) C program.

int n = (len + 8 - 1) / 8
switch(len % 8) {
  case 0: do { IOPORT = *pSource++;
  case 7:      IOPORT = *pSource++;
  case 6:      IOPORT = *pSource++;
  case 5:      IOPORT = *pSource++;
  case 4:      IOPORT = *pSource++;
  case 3:      IOPORT = *pSource++;
  case 2:      IOPORT = *pSource++;
  case 1:      IOPORT = *pSource++;
  } while(--n > 0);
}

Isn’t that sick?! …that’s what they call a “duff device”. Looks like someone tricked the parser ;-) It also reminds me on my old AMIGA demo coding times when we generated code without loops to get the optimal performance. On-the-fly binary code generation coded in assembler. I fear that will be considered just as sick these days ;-)

I think it’s a bit disappointing that you cannot post from google groups to an usual nntp newsgroups:

We don't offer a NNTP service at this time, so you can't post to Usenet
newsgroups via a Google Groups email address. 

Regards,
The Google Team

At least for me newsgroups are becoming a pain to use because there almost no free nntp server left that offer a decend amount of groups. Wish I could just use Google Groups for that.

At ApacheCon I was bugging Jason and Brett to give me a little jumpstart with writing my first maven2 plugin. (Thanks, guys!) Now I’ve finally submitted the maven2 minijar plugin to the mojo jira at codehaus. Originally I’ve developed it to reduce the dependencies of jci to make the drools guys happy …but now it looks like it could be useful for other projects as well. It’s not as sophisticated as proguard that does even remove dead code inside classes. It just works on the class level. But comparing the results the difference is usually not thaaaat big. And beside proguard is GPL the configuration is not really suitable for using it through maven. With the minijar plugin all you need to call is “mvn minijar:minijar” and it will go through all the dependencies and create the minimal required (compile-time) jars for the built artifact to work.

Building jar: commons-jci/target/jakarta-commons-jci-1.0-SNAPSHOT.jar
[minijar:minijar]
commons-jci-1.0-SNAPSHOT-minimal.jar.jar classes:44 dependencies:130 => 100.0%
commons-collections-3.1-minimal.jar.jar classes:446 dependencies:518 => 2.0%
core-3.1.0-minimal.jar.jar classes:1255 dependencies:1469 => 31.0%
groovy-all-1.0-jsr-03-minimal.jar.jar classes:915 dependencies:1220 => 47.0%
janino-2.3.7-minimal.jar.jar classes:333 dependencies:414 => 64.0%
commons-logging-api-1.0.4-minimal.jar.jar classes:13 dependencies:57 => 45.0%
commons-io-1.1-minimal.jar.jar classes:41 dependencies:98 => 48.0%
commons-lang-2.1-minimal.jar.jar classes:110 dependencies:161 => 2.0%

The codebase even already includes some code to support dependency inlining. That’s next on the todo list for this little side project.


Update: it’s already available in the mojo sandbox in svn

Mark Proctor one the authors of drools started using jci for drools. It’s really cool to see your babies being actually also useful to others. He was pushing for some changes which work out very well in the IMO. The drools guys seem to be very strict when it comes down to dependencies. The good thing is it let me create a maven2 plugin to reduce the dependencies to a minimum.

It’s a bit sad that I have currently have just too many things on the cards. So it’s even cooler to see other people helping out with javaflow. A few months ago I’ve started to port javaflow to ASM as BCEL is just in maintance mode (a bug fix release is coming up though) while ASM is a very healthy and active project. Eugene (one of the ASM developers) now picked up the torch and provided an ASM implementation for javaflow. Kohsuke is also keeping up the good work. I hope we soon can deprecate the BCEL implementation and work towards a 1.0 release once the ASM implementation has stabelized. Great stuff, guys!