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
interplay inlineExceptionHandler and target:jvm-1.6 #5805
Comments
Imported From: https://issues.scala-lang.org/browse/SI-5805?orig=1 |
@magarciaEPFL said:
|
@magarciaEPFL said:
which is part of method:
|
@magarciaEPFL said: |
@VladUreche said: |
@magarciaEPFL said: |
@magarciaEPFL said (edited on May 23, 2012 1:22:47 PM UTC):
(its callsites updated to read Therefore it's not a GenASM bug. |
@magarciaEPFL said: One of the problematic snippets is:
The ICode below corresponds to the above, and is received as input by
i.e. the
Looking at the expression with
|
@magarciaEPFL said:
|
@VladUreche said: |
@magarciaEPFL said:
I'll look into this bug but any implications for tail-calls you'll have to figure out yourself anyway! :) |
@magarciaEPFL said: The JVM-wise lub was set to With
|
@magarciaEPFL said: |
@VladUreche said: |
@magarciaEPFL said: |
There appears to be a problem with
InlineExceptionHandlers
.I noticed after compiling the compiler with
-target:jvm-1.6 -optimize
as of scala/scala@446de86
and later trying to run with the usual VM options that activate the new verifier:
java -Xverify:all -XX:+UseSplitVerifier -XX:-FailOverToOldVerifier
There is some mismatch between stack map frames as emitted vs as computed by the verifier:
The problem does not surface when the compiler is compiled with
-Yinline -Yclosure-elim -Ydead-code
There are two candidate culprits:
inameToSymbol()
,getCommonSuperClass()
.InlineExceptionHandlers
GenASM seems not to be the culprit because
inameToSymbol()
doesn't run at all (rather,getCommonSuperClass()
always hits thereverseJavaName
cache). And ifgetCommonSuperClass()
had a bug, we would have noticed already.First I tried diagnosing with ASM's
CheckClassAdapter
, http://asm.ow2.org/doc/faq.html#Q4 , but it finds no error.Thus we're left with
javap -c -private -verbose
, which does show a difference for the method in question:A question we could ask ourselves is: What performance gain (if any) does
InlineExceptionHandlers
buy us?If negative, null, or negligible, then, shouldn't we consider removing
InlineExceptionHandlers
from the pipeline? This question is unrelated to this bug but becomes more pressing because of it.Given that the build optimizes library and compiler, this bug means our build can't target 1.6 classfiles.
The text was updated successfully, but these errors were encountered: