Description Philipe Mulet 2001-10-10 22:50:43 EDT

>I have been wondering over time about compromises between code optimization 
>and potential side-effects lost at runtime.
>
>On the example below, I noticed that most compilers will ignore the sequence 
>'inline.next' in the generated bytecodes, only producing bytecode for the 
>constant field 'str', and thus no raising any NullPointerException at 
>runtime.
>
>public class Inline {
>     final String str = "hello";
>     public static void main(String argv[]) {
>          foo(new Inline());
>     }
>     Inline next;
>     static void foo(Inline inline) {
>          System.out.println(inline.next.str.length());
>     }
>}
>
>javac 1.2.2u would generate less aggressive code
>Method void foo(Inline)
>   0 getstatic #11 <Field java.io.PrintStream out>
>   3 aload_0
>   4 getfield #10 <Field Inline next>
>   7 pop
>   8 ldc #1 <String "hello">
>  10 invokevirtual #9 <Method int length()>
>  13 invokevirtual #12 <Method void println(int)>
>  16 return
>thus detecting cases where 'inline' would be null, but still would not 
>detect that in this case 'next' is null. Does this mean null can be treated 
>as a valid instance of 'Inline' regarding to accessing constant fields ?
>
>I have noticed similar behaviors with javac when eliminating receiver of 
>static message expressions/field accesses.



NOTES:

Philippe (7/7/99 10:51:51 AM)
	We should not be doing such optimized accesses as we do right now.

Philippe (10/4/99 4:11:32 PM)
	Javac 1.3 will inline as well, but not optimally:

Method void foo(Inline)
   0 getstatic #7 <Field java.io.PrintStream out>
   3 aload_0
   4 pop
   5 ldc #2 <String "hello">
   7 invokevirtual #8 <Method int length()>
  10 invokevirtual #9 <Method void println(int)>
  13 return

PM (8/10/00 5:43:53 PM)
	Constant propagation through variables is not propagating null 
constants. Thus we only need to worry about cases
	where some constant fields are part of the other field bindings 
(further on the right): 
			a.b.c.ConstantOne.d
	---> this should generate	a.b.c.ConstantOne.d, and not 
ConstantOne.d as currently.

	Proposal is to only to online inline constants located on the left 
portion of the name:
		Constant1.Constant2.Constant3.d ---> Constant3.d


	New behavior implemented and released. Note: we keep optimizing out 
prefixes of static field accesses, potentially
	thus missing some side-effects (generation of code in no value required 
mode). This is consistent with other compiler
	implementations.

PM (8/15/00 11:17:13 AM)
	Binary compatibility enforces the fact we have to inline final field 
constants, even though their receiver expression
	is not a constant. Backing up to old behavior for JCK compliance.

	Given Javac 1.3 is not generating any field access at all, we will be 
compliant with it, to the detriment of the specs.
	Need to keep an eye open, in case javac changes its behavior.