The Old Joel on Software Forum: Part 4 (of 5)

java runtime question

Hello all:
I'm a C/C++ guy by training and experience who is now tasked with reworking a large amount of Java code. One thing I'm finding (and apparently it's quite common all around) is a heavy reliance on using "this." as such:

void someFunc(int blahBlah, Foo hooHah)
{
this.blahBlah = blahBlah;
this.hooHah = hooHah;
}

This style offends my C++ sensibilities, but that's my problem. My question relates to what it makes the Java runtime do... I've heard that it somehow bloats the code (though exactly how is a mystery). From what I know, an access to "this.foo" should be just as fast--indeed identical-- as an access to plain old native-scope "foo". Right?

On a related note, what books do you recommend for a solid overview of JVM implementations?

thanks!

John Haren
Friday, April 30, 2004

> this.blahBlah = blahBlah;

Assigns blahBlah (the parameter ) to blahBlah (the member data variable).

I use "m_" to prefix my member data, so I'd be able to write this as:

m_blahBlah = blahBlah;

Christopher Wells
Friday, April 30, 2004

right, that's what I do... my question, more specifically, is does that usage force the VM into a run-time check, or does the compiler optimize it out, or what?

Also, I'm finding a lot of the following: in a class that extends Thread, calls to "this.Yield()" etc. WTF? The compiler bitches ("static members should be accessed in a static way") but lets it go. Where I'm from, this is an ERROR. What gives?

I'm getting pretty curious as to what's going on inside the JVM...

John Haren
Friday, April 30, 2004

There really are two separate things here. First, the "this.blahBlah" convention to identify member variables, as opposed to "m_blahBlah" or something. Second, the differences between accessing a local variable and a member variable.

The style thing is just a naming convention thing. You'll see plenty of java code that uses "this.blahBlah", and plenty that doesn't. Personally, I don't like it because it's less clear what "blahBlah" refers to in an arbitrary block of code, but that's ok.

The second piece is a little more substantial. If I remember correctly, member-variable accesses are slightly more expensive than local-variable accesses, and some coding conventions will recommend that if you're going to read the same member variable more than 3 times in a method, replace it with local variable access (be careful that the value can change between accesses if another thread can change it). In practice, it's hardly ever noticeable, and I'd prefer whatever is more readable/maintainable.

"Inside the Java Virtual Machine" is a pretty good book describing exactly what the VM is doing. It'd be a decent intro book if you were planning on writing a VM, and otherwise gives lots more under-the-covers info than the typical java programmer knows (or, usually, needs to know).

schmoe
Friday, April 30, 2004

And java lets you call static methods through an interface (Thread.currentThread().yield()), but (imho) it generally obscures the fact that you're calling a static method, so I much prefer just plain Thread.yield(). It's a style thing again, but I think this one's even less acceptable than "this.memberVariable".

schmoe
Friday, April 30, 2004

(not to mention that Thread.yield() is often a bad idea in itself...)

schmoe
Friday, April 30, 2004

I'm not sure what you are asking here. Are you questioning whether you should automatically assign the parameter's value to a datamember of the class and then work with that or is you question whether accessing a datamember of a class is faster if you say someMember vs. this.someMember.

If it is the latter question I am almost certain the answer is "no".

If it is the former then I would say you shouldn't be doing this unless you need the parameter value to stick around after the method returns.

name withheld out of cowardice
Friday, April 30, 2004

I doubt there is a speed hit from this usage since I fail to see a reason getting to the same variable would take different paths depending on what the code looked like. I would guess by now also that the compiler would optimize it to what you think would be the correct way of doing things. So it's mostly style, 'this' is in there for a reason (mostly for this reason so why not use it) although I do admit it can hide some problems although I think the compiler will tell you when you forget to add 'this'.

Also all static methods must be called from a class and not from an instance since they are technically global functions not tied to any particular instance. 'this' represents the current instance so calling this.yield() is incorrect. ClassName.yield() would be the way you call a static method.

Searching for OO Alternatives
Friday, April 30, 2004

John,

Your original question is actually about Java language/compiler, not JVM. Java language spec is quite explicit about such details, so you can check it to see:
“blahBlah” has to be interpreted as a parameter name in your example, even when it is on the left-hand side of assignment. “this.blahBlah” is the only way to reference the member variable.

This might be less convenient than C++ convention, but certainly more consistent. With C++, checking ARM was almost a must. Java language spec should provide enough info to know what your compiled program will do without knowing JVM implementation details.

If there is no parameter/local variable “blahBlah” to hide the member variable, then “this.blahBlah” and “blahBlah” mean exactly the same. It is again a moral obligation of the compiler to produce the same bytecode. Checked with Eclipse/JDK1.3 – same bytecode indeed.

Dmitri Chatokhine
Friday, April 30, 2004

> I've heard that it somehow bloats the code
> (though exactly how is a mystery).

I wrote a quick program to test this theory. Long story short, accessing with "this" doesn't generate any different code.

Test code: (please excuse any spacing issues).
public class test {
private int m_value;
private int value;
public void setMValue(int value) {
m_value = value;
}
public void setValue(int value) {
this.value = value;
}
}

This disassembles to:
---BEGIN---
Method test()
0 aload_0
1 invokespecial #1 <Method java.lang.Object()>
4 return

Method void setMValue(int)
0 aload_0
1 iload_1
2 putfield #2 <Field int m_value>
5 return

Method void setValue(int)
0 aload_0
1 iload_1
2 putfield #3 <Field int value>
5 return
---END---

As you can see, setValue and setMValue both do the same thing in the same number of cycles.

As other posters have pointed out, it comes down to matter of style, but I figured testing it out might be fun.

Joe Blandy
Friday, April 30, 2004

To Joe: huh... applying "science" to computer science... I like it! Answers the speed question pretty definitively, I'd say.

To all: thanks very much for the replies. I like this forum.

John Haren
Friday, April 30, 2004

Another possibility for the "this." convention. I'm coming from the C# world, and many people over here type "this." so they get the intellisense pop-up list of all their member variables.

I'd be very suprised if at least some of the Java environments didn't do the same thing.

Chris Tavares
Friday, April 30, 2004

Chris, the Java environments were doing that before the C# environments existed :).

As a former C++ programmer myself, I think what I got the most value out of was simply reading the official Sun specifications on the language and the VM. "The Java Language Specification", and "The Java Virtual Machine Specification".

Should be working
Friday, April 30, 2004

"Chris, the Java environments were doing that before the C# environments existed :)."

And, you had to know this was coming... Visual C++ was doing it before Java had IDEs. :)

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, April 30, 2004

For what it's worth, I actually prefer "this." to "m_" or other scope warts. It just makes it obvious it's going on without artificially changing the member name. Good thing all around in my book, and I'm willing to pay the three character price to get it.

Chris Tavares
Saturday, May 1, 2004