Posts Tagged ‘java internals’

Small java changes which should be in Java 7

Wednesday, April 8th, 2009

It’s ironic the stuff we get used to as developers. There’s so much we do repeatedly in every class or in every project or maybe even in every method yet we never realize that it’s probably best to add a new “feature” to java to make our life easier. While searching for some reading material on java’s handling of String (just to clear up some of my own personal doubts) I came across a very interesting OpenJDK sub-project, Coin. Coin, simply put, is a project to determine what small language changes should be added to JDK7. Wonderful, let’s see what people have come up with. And that’s just week 4 submissions.
(more…)

Simple concurrent In-memory cache for web application using Future

Wednesday, March 11th, 2009

In-memory cache’s can be extremely useful for small web applications where you don’t want to full-blown cache system like ehCache or simply can’t afford one. I recently had such a requirement and I must say that I kind of made a mess of it. The requirement was to cache User objects so that we didn’t have to make too many calls to the database. Let me just say outright that while such a cache is not the best idea in the world, it isn’t the worst either. When you simply need to cache a few objects to reduce the load on the db in a moderately loaded web-app, this implementation works just fine.

The service layer was my choice for the cache, I use the Controller -> Service -> DAO model in all my webapps mainly because it keeps the code clean and also because it makes it much easier to manage transactions across DAO’s. (more…)

Method inlining with the final keyword in java

Thursday, February 12th, 2009

I have noticed a lot of people on the internet asking about method inlining. The term generally arises whenever the final keyword is discussed. Basically, it is said that compilers inline methods which are declared final thereby avoiding the cost of putting them on the stack etc and thus improving performance drastically under heavy load conditions. The same is true for variables as well, their values are inlined thereby avoiding the cost of performing lookups at runtime. What nobody talks about is what exactly is inlining.

Consider the following class :

public class Inline {

	private int	i;

	public void methodA() {
		methodB();
	}

	public final void methodB() {
		i++;
                i--;
	}
}

methodB() is marked final in this case. It cannot be overriden. The compiler sees this and decides to alter the byte code of methodA() to instead look like this :

public void methodA() {
		i++;
		i--;
	}

methodB() has now been inlined into methodA() to save the cost of pushing a method onto the stack. This invocation will work faster than the earlier one although its almost impossible to determine how much faster without a proper production environment. It’s also important to note that java code is first compiled into byte code and then into runtime code by the JVM. This change of code takes place in the JVM and not during compilation. If you open your class file you will see nothing different in it from the source file.

final variables work in the same way except calls to them are replaced by their actual values because those are not going to change once they’re initialized.

It’s been said that the newer VM’s (ever since Hotspot) no longer provide benefits of marking methods and variables final as they deduce and mark them final on their own during runtime.