Re: JVM verifier vs. naive code generator

On 03/19/2011 09:57 PM, Soeren Sandmann wrote:
> Consider this fragment of Java code:
>
> int i, j;
>
> i = 100;
> for (i>= 0&& (j = 10) == 10)
> i = j;
>
> This is correct; j is not used without being initialized, and the Java
> compiler accepts it without complaints.


It is correct if you s/for/if/; I am going to assume that this is what
you meant. The equivalent code that I have is the following (many thanks
to javap -c):


public static void main(java.lang.String[]);
      Code:
        0: bipush 100
        2: istore_1
        3: iload_1
        4: iflt 18
        7: bipush 10
        9: dup
        10: istore_2
        11: bipush 10
        13: if_icmpne 18
        16: iload_2
        17: istore_1
        18: return


> This code can obviously be improved, and some fairly trivial
> optimizations will slim down the control flow graph enough to make it
> understandable to the verifier. However, it bugs me that I have to rely
> on optimizations in order to get working code, because, among other
> things, there is no way to be sure that it's sufficient in all cases.


If you look at the difference between javac and your code generator, you
will notice that the generation of short-circuit and is different. javac
essentially compiles it as


if (i >= 0) {
      if ((j = 10) == 10) {
          i = j;
      }
}


Your code generator, by contrast, roughly approximates:


boolean cond = i >= 0;
if (cond)
      cond = (j = 10) == 10;
if (cond)
      i = j;


> Is there a standard way to get around this problem? Ie., a systematic
> way to ensure that the code generated will not only be correct, but also
> verifiable?


I suppose the problem is in the generation of short-circuit operators.
If you branch to the 'else' target as soon as you fail a condition, you
essentially make the code identical to the nested case, which will be
correctly verifiable, since you can definitely ascertain that all of the
conditions have been hit in the body of the if statement. I wouldn't
call this an optimization, insomuch as a short-circuit and operator can
be called mere syntactic sugar for doing potentially highly-nested
condition statements.


--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Return to the comp.compilers page.
Search the comp.compilers archives again.