On Tue, Sep 1, 2009 at 5:44 PM, Mark Derricutt <m...@talios.com> 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 javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---