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
Optimizer leaves references to classes that have been eliminated by inlining #6546
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6546?orig=1 |
@paulp said: |
@magarciaEPFL said (edited on Oct 24, 2012 8:10:16 PM UTC):
However in
Candidate solution, below. |
@magarciaEPFL said:
With that,
|
Sarah Gerweck (gerweck) said: |
@magarciaEPFL said: |
Sarah Gerweck (gerweck) said: |
Sarah Gerweck (gerweck) said: |
@paulp said: |
@paulp said: |
I am running into a problem where the optimizer is not completely removing references to inner classes it has decided it doesn't need to output. This is a serious problem in JavaEE 6 environments that rely heavily on class detection. I don't know of any workaround if you want to use Scala + JavaEE 6 except to turn off inlining, which is a pretty severe performance penalty in some cases.
The problem is all due to the inliner. All the little inner classes that get generated to represent anonymous functions, inner objects, etc. are smartly subject to removal if they can be inlined. I like this feature, as it does a good job speeding up startup and reducing the PermGen cost of Scala.
However, the problem is that the inliner does not remove these elided classes from the inner-classes declaration that is part of the class file format for outer classes. This inner-classes declaration is a key part of how class scanners look for all annotated classes, which is a major part of JavaEE 6 containers. The container ends up complaining that some of your declared classes are not present because there's no physical .class file. In JBoss, one such error prevents your entire module from deploying as it fails verification.
Even though these inner classes are never required by any actual method bytecode, the compiler is wrong to declare that they exist. I've also seen it cause warnings in other tools, though this is the worst symptom I've seen. I'm hoping that we can get for this as part of 2.10 if not sooner. (I haven't looked to see if this issue is still present in the 2.10 line. Last time I tried using the 2.10 milestones it didn't work for me.)
Besides the poor Eclipse performance, the implications of no optimization is one of the issues that is raising concerns about further adoption of Scala. :-)
The text was updated successfully, but these errors were encountered: