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
The one-argument Class.forName must never be inlined #6789
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6789?orig=1 |
@retronym said: First of all, we need to find all the places where That gives us a bunch of methods in But then there are all the calls to Of course, this level of paranoia would also cause us to worry about changing the behaviour of I think that it is worthwhile to add protection for the known callers to But as to security, I think we'll have to document it as a caveat of compiling with |
@retronym said: retronym/scala@scala:2.10.x...retronym:ticket/6789 I'm still feeling a bit dirty about this, I'd like some feedback before proposing it as a pull request. |
@retronym said (edited on Jan 15, 2013 8:18:10 AM UTC):
Thanks for raising this. Another variation thereof: inline a method body from the compile time JDK, which refers to classes/methods that are not available on some alternative runtime JDK. A reasonable heuristic to approximate disabling 'cross library inlining' might be to only allow inlining from code that is provided to the compiler as source files or as .class files, but not as JAR files. Inlining of methods in the Scala standard library has all the same implications as the Java standard library, however if you disable that you lose an important class of performance wins. We have to think very carefully about defaults here, and find a way balance the needs of the 'closed world' users who want maximum performance vs the 'open world' users who need safety in the face of unknown runtime environments. -jason
|
See my comment in #5457. Inlining Class.forName across class boundaries will cause the wrong classloader to be used if the caller and callee were loaded from different classloaders. If the call is first expanded to the three argument form, inlining should be safe (because the call to this.getClass.getClassLoader is explicit rather than being performed by the jvm.)
This issue may very well apply to other classloader-sensitive methods as well.
Here's the skeleton of a test to document the issue. g1 and g2 should not display different behavior regardless of where classes are loaded from.
The text was updated successfully, but these errors were encountered: