Scala 2.11.4 #1204
Assignees
Labels
enhancement
Feature request (that does not concern language semantics, see "language")
Milestone
Comments
gzm0
added
the
enhancement
|
We cannot compile our partest suite with 2.11.4. It seems that the pattern matcher goes into some kind of infinite loop: /ping @adriaanm @gkossakowski |
|
Which project is that? Would scala/community-build#65 catch this? |
|
@gkossakowski No, it wouldn't. This is the The sources of this project are in https://github.com/scala-js/scala-js/tree/master/partest/src/main/scala/scala/tools |
|
I think including as much code to be compiled makes sense. The general rule would be: include everything that's relevant and valuable for the project and use excludes only when necessary (e.g. because tests are very expensive to run). |
|
I'll look into it: as a workaround: |
|
I tried compiling the partest project on master on 2.11.4 (after publish-local of the compiler project) but couldn't repro. Could you tell me the right sequence of commands? |
|
@adriaanm It sufficient to say: I have the suspicion that this is a JDK8 only issue (just realized I was using JDK8 when testing this). |
|
Also happens in JDK7. Trying JDK6. |
|
Also happens on JDK6 for me (but different reason): |
|
I'm on JDK8, and what you asked me to do is what I did without problem, so not sure :-( |
|
maybe you just need to up -Xmx ? |
|
I run under "-Xmx3g" |
|
Checking... |
|
Happens even with My |
|
sorry i was actually running under Xmx5200M (runner script was overriding it) |
|
I can build it on Linux with /usr/lib/jvm/java-1.7.0-openjdk-amd64/bin/java -Xms1024M -Xmx4G -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=768M -jar `dirname $0`/sbt-launch.jar "$@"MaxPermSize, maybe? |
but |
|
it compiles with 3G for me -- runner script: EDIT: also compiles fine with a 2G heap: (lots of deprecation warnings, guys!) |
|
could you narrow down which file is causing the problem? |
When you compile against the compiler API and you want to support 2.10.2+, you have to live with them. Note that this bunch was just introduced by 2.11.4. Until 2.11.2 we had only 3 or 4, and they are protected by implicit conversions in https://github.com/scala-js/scala-js/blob/master/compiler/src/main/scala/scala/scalajs/compiler/Compat210Component.scala |
How can I do that? |
gzm0
added a commit
to gzm0/scala-js
that referenced
this issue
Oct 30, 2014
gzm0
added a commit
to gzm0/scala-js
that referenced
this issue
Oct 30, 2014
Also bump partest version to 1.0.1.
I think those newly deprecated methods can be avoided on 2.10. Let me know if I can help -- this was part of the big reporting refactoring (to enable configuring error reporting). |
|
Pass -verbose to scalac? |
|
It happens on our CI as well. |
|
@adriaanm passing Further, note that using |
|
how embarrassing, off-by-one-boolean in NoSuppression |
|
-verbose works for me on the command line... maybe sbt is hiding the output? |
|
Well, So I don't know which compilation unit we choke on... |
|
-Ydebug? It's been a while since I had to dive in big projects for a repro... Is that a good sign? PS: scala/scala#4085 |
|
Debug doesn't help either :( It tells me: So I still don't know the CU it chokes on... |
|
@adriaanm this is one of the pattern matches that cause the out of memory: JSObjectConstr(fields map {
case (name, value) => (name, transformExpr(value))
})From OptimizerCore.scala So its a very simple, irrefutable pattern (up to null). This should really not take 3GB of memory to compile. |
|
Agreed :) how did you find it in the end? I'll look into it next week. |
|
Like this: diff --git a/src/compiler/scala/tools/nsc/transform/patmat/PatternMatching.scala b/src/compiler/scala/tools/nsc/tr
index ef50e08..448a3de 100644
--- a/src/compiler/scala/tools/nsc/transform/patmat/PatternMatching.scala
+++ b/src/compiler/scala/tools/nsc/transform/patmat/PatternMatching.scala
@@ -57,6 +57,10 @@ trait PatternMatching extends Transform
class MatchTransformer(unit: CompilationUnit) extends TypingTransformer(unit) {
override def transform(tree: Tree): Tree = tree match {
case Match(sel, cases) =>
+ println("Translating match!")
+ println(" Compilation unit: " + unit)
+ println(" Pos: " + tree.pos)
+ println(" Tree: " + tree)
val origTp = tree.tpe
// setType origTp intended for CPS -- TODO: is it necessary?
val translated = translator.translateMatch(treeCopy.Match(tree, transform(sel), transformTrees(cases).asI
@@ -69,6 +73,9 @@ trait PatternMatching extends Transform
translated
}
case Try(block, catches, finalizer) =>
+ println("Translating try!")
+ println(" Compilation unit: " + unit)
+ println(" Tree: " + tree)
treeCopy.Try(tree, transform(block), translator.translateTry(transformTrees(catches).asInstanceOf[List[Ca
case _ => super.transform(tree)
}Is it any use to you if I try to remove code around it? I'll try freezing the hierarchy we match against (by adding some finals) in the hope this solves it. |
|
Yeah, I really don't understand why this would be taking so long/so much memory. Can you confirm that rewriting without a match makes the problem go away? /cc @gbasler, who has the patmat analysis logic fresh in mind (I'm a bit rusty) |
|
I'll try to rewrite without pattern match. (However, there are many of these matches, so it might take me a while to evict them one-by-one). |
gzm0
added a commit
to gzm0/scala-js
that referenced
this issue
Oct 31, 2014
Also bump partest version to 1.0.1.
|
maybe go first for one with more cases/alternatives/sealed hierarchy |
|
They all basically match on the same tree hierarchy. |
|
Even a match like this fails: val body = cases collectFirst {
case x if x._1.exists(literal_===(_, newSelector)) => x._2
} getOrElse defaulttranslated from val body = cases collectFirst {
case (alts, body) if alts.exists(literal_===(_, newSelector)) => body
} getOrElse default |
|
If also found matches like this failing: x match {
case x: Literal => // x
case _ => // y
}where literal is a sealed sub trait of |
|
Something self-contained I can try would be great. |
|
What's wrong with the Scala.js build itself (or more precisely the tools project)? There probably is a need for a quite large class hierarchy to reproduce this. And if the Scala.js build doesn't trigger this on your environment, it is unlikely that anything more self-contained will. |
|
Btw. I could reproduce this on my laptop: |
|
Also on JDK7: |
|
@adriaanm I could reproduce the error, just checked out gzm0's branch and run A quick fix would be to abort the loop and issue a warning if e.g. more than 10 variables (=2^10 models) are expanded... sorry my bad I should have thought of that before... There should be a nicer solution though - the expand unassigned can be avoided by just allowing unassigned variables in the model and then returning a list of counter examples in |
|
I realized that limiting the number of variables that are expanded results in the same non deterministic behavior that I tried to fix. |
|
Back-Published Scala.js v0.5.{0-5} for 2.11.4 |
|
@gbasler is this filed as an SI somewhere already? |
gzm0
added a commit
to gzm0/scala-js
that referenced
this issue
Nov 4, 2014
|
Filed as SI-8999 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: