ZipFileSystemProvider backed classpath impl, to avoid ZipFile lock contention #115
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The problem with this change is that if it introduces cross talk between the the compiler loaded in multiple classloaders (either concurrently or in sequence). |
|
That's not a problem if we create it with |
retronym
force-pushed
the
faster/zipfs
branch
8 times, most recently
from
137911a to
45e5c24
Compare
Co-authored-by: Seth Tisue <[email protected]>
Co-authored-by: Seth Tisue <[email protected]>
Just like in Scala 3.0, adding this keyword doesn't change anything, but it will be required in future versions of Scala 3 for non-exhaustive patterns in a for comprehension. We would like to start issuing warnings by default in Scala 3 for code which does not use `case` in those situations, but to not hamper cross-compilation we need Scala 2 to also support that keyword. For details, see: https://dotty.epfl.ch/docs/reference/changed-features/pattern-bindings.html
Like in Scala 3.0, this allows `?` to be used as a type argument in all situations where `_` could be used as a wildcard previously. This should allow us to deprecate the use of `_` as a wildcard in Scala 3 to be able to eventually repurpose it as explained in http://dotty.epfl.ch/docs/reference/changed-features/wildcards.html This is a source-breaking change since a type named `?` is legal in Scala 2 (but not in Scala 3 unless -source 3.0-migration is used). `?` also has a special meaning when the kind-projector plugin is used, but that usage has been deprecated in favor of `*` for a while now.
Instead of:
import foo._
One can now write:
import foo.*
and instead of:
import foo.{bar => baz}
One can now write:
import foo.{bar as baz}
As well as:
import foo.bar as baz
This will let us deprecate the old syntax in a future release of Scala
3 (it's currently only deprecated under `-source future`).
See http://dotty.epfl.ch/docs/reference/changed-features/imports.html
for details but note that unlike Scala 3 this commit does not implement
support for:
import java as j
As that would require deeper changes in the compiler.
Instead of:
foo(s: _*)
One can now write:
foo(s*)
And instead of:
case Seq(elems @ _*) =>
One can now write:
case Seq(elems*) =>
See https://dotty.epfl.ch/docs/reference/changed-features/vararg-splices.html
for details.
Since everything is open and can be used infix by default in Scala 2, these keywords are no-op, but they're useful for cross-compiling with a future version of Scala 3 where they will be required in some cases (with Scala 3.0 they're only required to avoid warnings under `-source future`). See https://dotty.epfl.ch/docs/reference/changed-features/operators.html and http://dotty.epfl.ch/docs/reference/other-new-features/open-classes.html for details.
[backport] Support for Scala 3 syntax under `-Xsource:3`
Instead of:
val x: A with B = new A with B {}
One can now write:
val x: A & B = new A with B {}
However mixing `&` with other infix operators is not allowed, because
unlike Scala 3, we do not take operator precedence into account, cf scala#6147.
This implementation is a bit more restrictive than the Scala 3 one which
allows shadowing the built-in `&` with your own `&` type operator, but
this cannot be done with the simple parser-based approach of this PR.
Add null check for getURLs-method
[backport] Support writing `&` instead of `with` in types under `-Xsource:3`
This prevents concurrent compilers with different values for this compiler option from seeing the incorrect API.
Classpath elements based on a) jrt:// file system (representing platform libraries of the current the Java 9+ instance) and b) ct.sym (the JEP 247 repository of the of previous JDK versions) are an immutable part of the JDK. The ClassPath entries we create are safe to share across concurrent or subsequent compilers in the same way we cache entries for regular JARs.
Classpath caching shares a single instance of ZipArchive across multiple threads. This can cause read contention as j.u.ZipFile internally serializes reads. Instead, maintain a pool of ZipFile instances to avoid sharing them across threads.
The current optimized version tries to avoid temporary strings. But it doesn't achieve this for classes based by jrt:// (or any `NioPath`, as the call to `AbstractFile.fileName` internally constructs a string each time. This commit uses `.name` (which is a `lazy val`).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.