On Tue, Sep 1, 2009 at 5:44 PM, Mark Derricutt <[email protected]> wrote:
> I've always been intrigued by these blocks we have in java, what does javac
> actually generate for them?
Not much. It just reuses slots. But don't take my word for it
~/test$ cat Test.java
public class Test {
public void test() {
int foo = 1;
{
int bar = foo + 2;
System.out.println("inner bar = " + bar);
}
int bar = foo + 3;
System.out.println("outer bar = " + bar);
}
}
~/test$ javac Test.java
~/test$ javap -c -private Test
Compiled from "Test.java"
public class Test extends java.lang.Object{
public Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
public void test();
Code:
0: iconst_1
1: istore_1
2: iload_1
3: iconst_2
4: iadd
5: istore_2
6: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
9: new #3; //class java/lang/StringBuilder
12: dup
13: invokespecial #4; //Method java/lang/StringBuilder."<init>":()V
16: ldc #5; //String inner bar =
18: invokevirtual #6; //Method
java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
21: iload_2
22: invokevirtual #7; //Method
java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
25: invokevirtual #8; //Method
java/lang/StringBuilder.toString:()Ljava/lang/String;
28: invokevirtual #9; //Method
java/io/PrintStream.println:(Ljava/lang/String;)V
31: iload_1
32: iconst_3
33: iadd
34: istore_2
35: getstatic #2; //Field
java/lang/System.out:Ljava/io/PrintStream;
38: new #3; //class java/lang/StringBuilder
41: dup
42: invokespecial #4; //Method java/lang/StringBuilder."<init>":()V
45: ldc #10; //String outer bar =
47: invokevirtual #6; //Method
java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
50: iload_2
51: invokevirtual #7; //Method
java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
54: invokevirtual #8; //Method
java/lang/StringBuilder.toString:()Ljava/lang/String;
57: invokevirtual #9; //Method
java/io/PrintStream.println:(Ljava/lang/String;)V
60: return
}
The instructions istore_2 and iload_2 each appear twice (the stores happen
after the adds, the loads appear before the string builds). That's javac
reusing the same slot in the local variable table since the inner "bar" is
no longer needed when it encounters the outer "bar." slot 1 is tied to foo
for the enitre method. const 1 is 1, const 2 is 2, and const 3 is 3.
> I'd always hoped that the closures proposals might just start small and
> make these blocks a first class citizen.
>
Closures are more complicated than simple blocks. Because closures capture
variables into potentially long lived objects that transcend normal stack
behavior, mutable variables need to be heap allocated. That, by the way, is
why Java's existing sorta-closures (instances of anonymous inner classes)
are only allowed to capture final variables. In Java 1.2 the largest users
of Java were C++ programmers who were mortified at the thought of Java
silently introducing extra heap allocation without explicit "new".
http://madbean.com/2003/mb2003-49/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
