2

I was wondering if all control flow graphs obtained from a typical JVM bytecode (see how to) of a single method (no recursion allowed) could be translated back to equivalent ifs and whiles code.

If not, what is the smallest JVM bytecode sequence which cannot be translated back to ifs and whiles ?

Community
  • 1
  • 1
Mikaël Mayer
  • 10,425
  • 6
  • 64
  • 101
  • This question appears to be off-topic for SO because it is not on a specific implementation problem. It belongs better to Programmers.SE – Seki Feb 26 '14 at 11:47

2 Answers2

5

There are several reasons why bytecode control flow may not be translatable back into Java without extreme measures.

  • JSR/RET - this instruction pairs has no equivalent in Java. The best you can do is inline it. However, this will lead to an exponential increase in code size if they are nested.

  • Irreducible loops - In Java, every loop has a single entry point which dominates the rest of the loop. An "irreducible" loop is one that has multiple distinct entry points, and hence no direct Java equivalent. There are several approaches. My preferred solution is to duplicate part of the loop body, though this can lead to exponential blow up in pathological cases as well. The other approach is to turn the method into a while-switch state machine, but this obscures the original control flow.

An example instruction sequence is

ifnull L3
L2: nop
L3: goto L2

This is the simplest possible irreducible loop. It is impossible to turn into Java without changing the structure or duplicating part of the code (though in this case, there are no actual statements so duplicating wouldn't be so bad).

  • The last part is exception handling. Java requires all exception handling to be done through structured try/catch blocks and it's variations while bytecode doesn't. At the bytecode level, exception handlers are basically another form of goto. In pathological cases, the best you can do is create a seperate try catch for every instruction that throws and repeat the process above.
Antimony
  • 37,781
  • 10
  • 100
  • 107
  • Note however that `jsr` and `ret` got deprecated with Java 6. – Rafael Winterhalter Feb 27 '14 at 07:38
  • @raphw But thanks to backwards compatibility, they'll always be a concern. – Antimony Feb 27 '14 at 14:45
  • True, but the OP asked about typical byte code. Most libraries are compiled for Java 6 and up these days. – Rafael Winterhalter Feb 27 '14 at 18:32
  • @raphw Typical bytecode is compiled straight from Java, so it can always be turned back into Java (admittedly real world decompilers have limits so sufficiently complicated Java will still mess them up). – Antimony Feb 27 '14 at 22:13
  • Actually the method proposed in the DREAM decompiler framework will remove unstructured entries to loops by introducing variables and adding conditionals. It is a much better method than code duplication or a state machine which are naive and generic ideas that dont match the problem. The paper associated with DREAM has all the details, it produces goto free code without code duplication. Though they focus on C the ideas apply to Java byte code – Gregory Morse Jun 07 '21 at 21:51
1

I think a jump into the middle of a loop is not expressible in structured code:

JMP L1 // jump into the middle of a loop
L2:
IFCMP L3 // loop condition
// do something inside the loop
L1:
// do something else inside the loop
JMP L2
L3:
// exit the loop

Sorry, this is not exactly JVM bytecode, but you can get the idea.

Andrey Breslav
  • 24,795
  • 10
  • 66
  • 61
  • 1
    This example is wrong, since you still only have one entry point. But the basic idea is correct. – Antimony Feb 26 '14 at 14:30
  • Obviously any code can be represented as a state machine e.g. while (1) {switch (state) { case 0: state=1; break; case 1: state=2; break; case 2: if (cond) state=3; else state=1; break; ... }. So this answer is contradicting the most basic of theory on the issue. – Gregory Morse Jan 25 '22 at 04:12