Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

generation of unreachable bytecode #7006

Closed
scabug opened this issue Jan 22, 2013 · 5 comments
Closed

generation of unreachable bytecode #7006

scabug opened this issue Jan 22, 2013 · 5 comments

Comments

@scabug
Copy link

scabug commented Jan 22, 2013

scalac generates bytecode which is unreachable. This problem affects performance.
I am enclosing two example:
1 - Look at method Test.crazy. From bytecode 68 to 76.
2 - Look at method KevoreeLazyJarResources.loadJar(jarFile:String). From 148 to 159.
I realized this because I am extending a JVM. The code run with JavaHotSpot but any way, this is not correct. The really weird is that in former case a lot of nop are generated. however, in the latter case it looks like if some code is duplicated. Maybe a potential source of bug

@scabug
Copy link
Author

scabug commented Jan 22, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7006?orig=1
Reporter: Inti Gonzalez (inti)
Assignee: @JamesIry
Affected Versions: 2.9.2, 2.10.0-RC2
See #7181
Attachments:

@scabug
Copy link
Author

scabug commented Feb 20, 2013

@JamesIry said:
Some amount of code duplication is a consequence of bytecode format 51 (the Java 6 bytecode format). With that rev the jsr and ret instructions are no longer usable. The result is that finally blocks need to be duplicated. Here's an approachable introduction: http://cliffhacks.blogspot.com/2008/02/java-6-tryfinally-compilation-without.html . Still, it should be possible to avoid some of the duplication by recognizing cases where flow out of a finally block is identical.

An alternative would be to lift finally blocks into methods, but that would mean boxing mutable variables and we'd need a heuristic to decide when one alternative was better than the other.

I'm investigation why we spit out so many nops and what it would take to avoid them during non-optimized builds. It's definitely feasible to drop them in the optimizer, but it would be nicer to just not have them.

@scabug
Copy link
Author

scabug commented Feb 20, 2013

@magarciaEPFL said:
Regarding unreachable code. The new backend solves that issue, and the fix can be ported to GenASM. Here's the gist:

    /**
     *  When writing classfiles with "optimization level zero" (ie -neo:GenBCode)
     *  the very least we want to do is remove dead code beforehand,
     *  so as to prevent an artifact of stack-frames computation from showing up,
     *  the artifact described at http://asm.ow2.org/doc/developer-guide.html#deadcode
     *  That artifact results from the requirement by the Java 6 split verifier
     *  that a stack map frame be available for each basic block, even unreachable ones.
     *
     *  Just removing dead code might leave stale LocalVariableTable entries
     *  thus `cleanseMethod()` also gets rid of those.
     * */
    final def removeDeadCode() {
      for(mnode <- cnode.toMethodList; if Util.hasBytecodeInstructions(mnode)) {
        Util.computeMaxLocalsMaxStack(mnode)
        cleanseMethod(cnode.name, mnode) // remove unreachable code
      }
    }

Excerpt from https://github.com/magarciaEPFL/scala/blob/GenRefactored/src/compiler/scala/tools/nsc/backend/jvm/BCodeOptIntra.scala

The ASM visitors used in cleanseMethod() can be found at https://github.com/magarciaEPFL/scala/tree/GenRefactored/src/asm/scala/tools/asm/optimiz

@scabug
Copy link
Author

scabug commented Feb 23, 2013

@JamesIry said:
scala/scala#2158

@scabug
Copy link
Author

scabug commented Feb 25, 2013

@JamesIry said:
I've created a separate ticket #7181 to deal with the finally block duplication

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant