GRAYGER

I saw a presentation on Java VM optimization via InfoQ. Java is originally slow, but HotSpot compiler is getting smarter enough to free Java from the shame.

http://www.infoq.com/presentations/pampuch-vm-optimizations-language-designers

Detecting deadlock is one of common features of Java profiling tools but I haven’t experienced the situation where those tools detect deadlock from code I wrote. In fact, deadlock is hazardous because it is difficult to predict and reproduce.

I wondered under what conditions do profilers detect deadlock and then report it, so I wrote code that reaches deadlock.

package com.grayger.deadlock;

public class SimpleDeadlocker {
	private final static Object OBJ1=new Object();
	private final static Object OBJ2=new Object();

	private final static int LOOP=100;

	public void obj1First() {
		synchronized(OBJ1) {
			printInfo("Hold OBJ1");
			synchronized(OBJ2) {
				printInfo("Hole OBJ2");
			}
			printInfo("Release OBJ2");
		}
		printInfo("Release OBJ1");
	}

	public void obj2First() {
		synchronized(OBJ2) {
			printInfo("Hold OBJ2");
			synchronized(OBJ1) {
				printInfo("Hole OBJ1");
			}
			printInfo("Release OBJ1");
		}
		printInfo("Release OBJ2");
	}

	private void printInfo(String info) {
		System.out.println(Thread.currentThread().getName()+" "+info);
	}

	public static void main(String args[]) {
		final SimpleDeadlocker d=new SimpleDeadlocker();
		Thread t1=new Thread(new Runnable() {
			public void run() {
				for(int i=0;i<loop;i++)>
					d.obj1First();
				}
				d.printInfo("Terminated");
			}
		}, "OBJ1_First");

		Thread t2=new Thread(new Runnable() {
			public void run() {
				for(int i=0;i<loop;i++)>
					d.obj2First();
				}
				d.printInfo("Terminated");
			}
		}, "OBJ2_First");

		t1.start();
		t2.start();
	}
}

Above example can be refactored as follows:

package com.grayger.deadlock;

public class Deadlocker {
	private final static int LOOP=100;

	static class Deadlock1 {
		private final static Object OBJ1=new Object();
		private final static Object OBJ2=new Object();		

		public void obj1First() {
			synchronized(OBJ1) {
				printInfo("Hold OBJ1");
				synchronized(OBJ2) {
					printInfo("Hole OBJ2");
				}
				printInfo("Release OBJ2");
			}
			printInfo("Release OBJ1");
		}
	}

	static class Deadlock2 {
		private final static Object OBJ1=new Object();
		private final static Object OBJ2=new Object();

		public void obj2First() {
			synchronized(OBJ2) {
				printInfo("Hold OBJ2");
				synchronized(OBJ1) {
					printInfo("Hole OBJ1");
				}
				printInfo("Release OBJ1");
			}
			printInfo("Release OBJ2");
		}
	}

	public static void printInfo(String info) {
		System.out.println(Thread.currentThread().getName()+" "+info);
	}

	public static void main(String args[]) {
		final Deadlock1 d1=new Deadlock1();
		final Deadlock2 d2=new Deadlock2();
		Thread t1=new Thread(new Runnable() {
			public void run() {
				for(int i=0;i<loop;i++)>
					d1.obj1First();
				}
				Deadlocker.printInfo("Terminated");
			}
		}, "OBJ1_First");

		Thread t2=new Thread(new Runnable() {
			public void run() {
				for(int i=0;i<loop;i++)>
					d2.obj2First();
				}
				Deadlocker.printInfo("Terminated");
			}
		}, "OBJ2_First");

		t1.start();
		t2.start();
	}
}

The @Override annotation added in Java5 is very useful. Recently I found out the annotation of Java6 differs from that of Java5. Java6 allows annotating a method that implements a method declared in interface with @Override whereas Java5 doesn’t allow it.

Unfortunately I couldn’t find any document on the change from java.sun.com site. Missing this issue from the release note of Java6 seems to be a mistake as http://blogs.sun.com/ahe/entry/override_snafu says.

Donald Knuth, the advocate of literate programming, gave his opinion on code reuse from an interview by Andrew Binstock

I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.

In my view, literately programmed code should be visible for every programmer through its evolution, so literate programming doesn’t cope with OCP well. I guess it is why he prefer “re-editable” code to reusable black box code. But I think benefits of information hiding can be sacrificed in no case.