-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Use proxy-based serialization for modules #7297
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Should this be marked [nomerge] as we cant apply this to 2.12 because of serialisation binary compat |
As we are asserting that this work well with a SecurityManager, with minimal permissions (i.e. Scala.* has reflect access), there should be a test for that |
src/compiler/scala/tools/nsc/typechecker/SyntheticMethods.scala
Outdated
Show resolved
Hide resolved
I'll rebase and improve the comment. |
8976c9b
to
f3f9ab5
Compare
This avoids serializing any state of serializable singletons which would be discarded anyway after deserializing (SI-10412). Use ClassValue to cache instances, which is significantly faster for subsequent deserialization of a given module. ClassValue entries only weakly reference the key and value so the class can be unloaded. Wrap use of reflection in AccessControler to play nicely under SecurityManager. A security manager will only walk up the stack to this point to check permissions, so if users grant scala-library permissions in the policy, the call will be allowed regardless of the code higher in the stack that has triggered deserialization.
I can't really figure out how to (or maybe, muster the energy to) rig up a test for this. I think it would require me to run a forked JVM with a security manager and a setting for
That's only required for changes committed to 2.12.x that shouldn't/needn't be merged forward to 2.13.x. |
@retronym I don't think that it is as complex as that for the test. I will pop one in a separate new PR great to see this merged 😄 |
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serializable in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
In scala#4450 and Scala 2.12, readResolve is used to make sure deserializing an object returns the singleton instance of the object, but this doesn't prevent the fields of the objects from being serialized in the first place even though they're not used. Scala 2.13 switched to using writeReplace to completely bypass serialization of the object in scala/scala#7297. This commit adapts this to Dotty. Co-Authored-By: Ingar Abrahamsen <ingar@abrahams1.com> Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
This avoids serializing any state of serializable singletons which
would be discarded anyway after deserializing (SI-10412).
Use ClassValue to cache instances, which is significantly faster for
subsequent deserialization of a given module. ClassValue entries only
weakly reference the key and value so the class can be unloaded.
Wrap use of reflection in AccessControler to play nicely under
SecurityManager. A security manager will only walk up the stack
to this point to check permissions, so if users grant scala-library
permissions in the policy, the call will be allowed regardless of
the code higher in the stack that has triggered deserialization.
(Rebase and extension of #6877)
Fixes scala/bug#10412