-
Notifications
You must be signed in to change notification settings - Fork 21
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
UnCurry forgets to liftTree, causing java.lang.VerifyError down the road #6863
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6863?orig=1
|
Alex Turcu (talex) said: def test(kryo: Kryo, input:Input, typ: Class[Map[_,_]]): Map[_,_] = {
val len = 7
var coll: Map[Any, Any] = {
try {
val someVar = null;
Map[Any,Any]().empty
} catch {
case _ => Map[Any,Any]().empty
}
}
0 until len foreach {_ => coll += Tuple2( 0, 0) }
coll
} Looks similar to #5380 , and seems to be related to the wrapping of "coll" into a scala.runtime.ObjectRef . someVar is required but probably just prevents some other optimization. |
@magarciaEPFL said: |
Alex Turcu (talex) said: object Main extends App {
def test(): Map[_,_] = {
//val typ = classOf[Map[Int,Int]]
var coll: Map[Int, Int] = {
val key = 4
try {
Map[Int,Int](key -> 5).empty
} catch { case _ => Map[Int,Int](2 -> 3).empty }
}
0 until 7 foreach {_ => coll += Tuple2( 0, 0) }
coll
}
} It fails for me using 2.10.0-RC5 and: #!/bin/bash
rm ./*.class
scalac bug.scala
scala -classpath . Main |
@magarciaEPFL said:
After compiling with v2.10.0 and master we get:
|
@magarciaEPFL said: |
@magarciaEPFL said:
Two blocks (B1 and B2) get merged at instruction 12. B1 comprises instructions [0 to 7] and B2 (an exception handler) [10 to 11]. On exit from B1, the stack is Usually
That would have saved the day. |
@JamesIry said (edited on Jan 8, 2013 6:19:35 PM UTC): |
@JamesIry said: Remove some redundant code Remove the code that it was redundant to, so now it Then destroy the evidence that it ever existed Moral of the story: tests are good. |
@JamesIry said: |
@magarciaEPFL said: NEW ObjectRef
DUP
... instructions loading initialValue
INVOKESPECIAL scala.runtime.ObjectRef.<init>(initialValue) Alternatively, if the above were lowered into: ... instructions loading initialValue
INVOKESTATIC scala.runtime.ObjectRef.create(initialValue) then UnCurry wouldn't need to anticipate anything (no code resurrection, no code duplication, more compact code). For bonus points, it would be great to have: INVOKESTATIC scala.runtime.ObjectRef.zero() which returns an About binary compatibility, what if |
@JamesIry said: |
@JamesIry said (edited on Jan 18, 2013 4:49:17 PM UTC): var x = try{...}catch{...} transforms to val temp$ = try {...}catch{...}
var x = temp$ which, when x is captured, turns turns into ... instructions loading initialValue
STORE temp$
NEW ObjectRef
DUP
LOAD temp$
INVOKESPECIAL scala.runtime.ObjectRef.<init>(initialValue) It wastes a variable slot in cases when var is not captured, though (unless we're smarter about optimizing away variables than I think we are), so we'd want to replace it with the cleaner static factory version in 2.11. |
@adriaanm said: |
@magarciaEPFL said: var temp = try {} catch {}
new Foo(temp) I agree getting this fixed first in a binary-compatible way is the best for now. |
@JamesIry said: |
@JamesIry said: The pull is: scala/scala#1927 A proposed alternative for 2.11+ is here: http://james-iry.blogspot.com/2013/01/scala-trycatch-lifting-proposal.html |
@magarciaEPFL said: A proposal (in the form of pseudocode) for that transformation can be found at https://groups.google.com/d/msg/scala-internals/VkEL7wOVQpE/aSiNnF3ym-cJ |
I'm trying to use a modified version of https://github.com/romix/akka-kryo-serialization with Scala 2.10.0-RC5. It compiles fine (without -optimise, with the flag it crashes, but that's a different issue), but then at class load-time I get the following error:
Even Soot refuses to load the class properly, and gives the following:
The code that causes the problem appears to be at the end of this block, as the three branches are collected into the final result (line labeled 111 in the 2.10 bytecode file):
This code worked on 2.9.1, and it appears the generated bytecode is indeed different. I've attached the source code excerpt and disassembled bytecode for 2.9.1 and 2.10.0-RC5, and highlighted the line with the problem in the 2.10 bytecode.
The text was updated successfully, but these errors were encountered: