Skip to content
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

Update Zinc to 1.6.0 and drop the fork #1662

Merged
merged 3 commits into from
Feb 21, 2022

Conversation

tgodzik
Copy link
Contributor

@tgodzik tgodzik commented Jan 21, 2022

No description provided.

@tgodzik tgodzik force-pushed the update-newest-zinc branch 4 times, most recently from dfd8e35 to f29bf6d Compare January 24, 2022 18:47
@@ -142,12 +149,26 @@ final class BloopClassFileManager(
}
}

// Idea taken from the default TransactionalClassFileManager in zinc
// https://github.com/sbt/zinc/blob/c18637c1b30f8ab7d1f702bb98301689ec75854b/internal/zinc-core/src/main/scala/sbt/internal/inc/ClassFileManager.scala#L183
val toBeBackedUp = (classes ++ invalidatedExtraCompileProducts).filter(c =>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously, Bloop was using forked Zinc, that allowed to invalidate all symbols from invalidated files from the compiler. That API is not available for the mainline Zinc though, so we need to move them explicitely.

@tgodzik tgodzik force-pushed the update-newest-zinc branch from f29bf6d to e6decfe Compare January 25, 2022 14:19
@bloopoid
Copy link
Collaborator

Performance test finished successfully.

Benchmarks is based on merging with master

@tgodzik tgodzik force-pushed the update-newest-zinc branch from e6decfe to 243306e Compare January 26, 2022 15:14
@bloopoid
Copy link
Collaborator

Performance test finished successfully.

Benchmarks is based on merging with master

2 similar comments
@bloopoid
Copy link
Collaborator

Performance test finished successfully.

Benchmarks is based on merging with master

@bloopoid
Copy link
Collaborator

Performance test finished successfully.

Benchmarks is based on merging with master

@tgodzik tgodzik force-pushed the update-newest-zinc branch from 243306e to fc2d635 Compare January 31, 2022 18:10
@@ -20,17 +20,25 @@ final class ScalaInstance private (
override val version: String,
override val allJars: Array[File]
) extends xsbti.compile.ScalaInstance {
override val compilerJar: File = {

override lazy val loaderCompilerOnly: ClassLoader =
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is based on sbt itself.

val modifiedLibraries = initialChanges.libraryDeps.toArray

val modifiedBinaries: Array[File] = modifiedLibraries.map(converter.toPath(_)).collect {
case path if !isJrt(path) =>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this one. Class files from the JDK are represented as jrt: (so I think it corresponds) and can't be cast to java.io.File, but on the other hand modifiedBinaries is deprecated so this should not be an issue.

previousAnalysis: Analysis,
stamps: ReadStamps,
lookup: Lookup,
converter: FileConverter,
output: Output
)(implicit equivS: Equiv[XStamp]): InitialChanges = {
tracer.traceVerbose("detecting initial changes") { tracer =>
// Copy pasting from IncrementalCommon to optimize/remove IO work
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked the recent changes and updated.

// The hash is for the sources
BloopStamps.forHash,
Stamper.forLastModified
Stamper.forHashInRootPaths(converter)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hash seems enought for libraries, it doesn't look like we need last modified. This also started failing with jrt path issues.

case _ =>
}

val outputOption = CompilerArguments.outputOption(output)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's needed to specify the output directory now, otherwise it will get compiled next to the source file. The change is based on changes to zinc/sbt

Copy link

@romanowski romanowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit worried about tons of allocations we introduce with all this Path / FIle >=> VirtualFile conversions. I guess we would need to profile the bloop to see how much of the effect it will have.

backend/src/main/scala/bloop/BloopClassFileManager.scala Outdated Show resolved Hide resolved
backend/src/main/scala/bloop/CompilerCache.scala Outdated Show resolved Hide resolved
@@ -60,7 +68,25 @@ final class ScalaInstance private (
filename.startsWith(ScalacCompilerName) ||
(isDotty && (filename.startsWith("dotty-compiler") || filename.startsWith("scala3-compiler")))
private def hasScalaLibraryName(filename: String): Boolean =
filename.startsWith("scala-library")
filename.startsWith("scala-library") || filename.startsWith("scala3-library")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really do not like how it works... Maybe we can change bloop options at some point to pass compiler jars more directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not perfect, but we would need to split the Scala configuration to have two lists and we would most likely move this part to the integrations (which might also just have a single Scala classpath). Overall I feel it's better to keep it here and besides allJars are only Scala jars, so no user defined libraries will pop up here.

The only risk is if someone forks the compiler, but then a lot more things could break.

@@ -386,8 +380,8 @@ private[inc] class BloopComponentCompiler(
val allSourceContents =
(hydraSourceContents ++ regularSourceContents).map(s => s -> relativize(tempDir, s).get)

zip(allSourceContents.toSeq, mergedJar)
Right(Vector(mergedJar))
zip(allSourceContents.toSeq, mergedJar, time = None)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Do we have other palces in bloop where we zip some files?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not from what I can see, this is for the compiler bridge compiled sources.

val previous = previous0 match { case a: Analysis => a }
classfileManager.delete(invalidatedSrcs.flatMap(previous.relations.products).toArray)
val toDelete = invalidatedSrcs.flatMap(previous.relations.products).toArray.collect {
case vf: VirtualFile => vf

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we get anything else then VirtualFile here (like a entry in the jar)? If so, shouldn't we somehow invalidate

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not really have anything else, classFileManager only works with VirtualFile, so I don't imagine anything else is normally handled.

.map(converter.toPath(_))
.collect {
// jrt path is neither a jar nor a normal file
case path if !isJrt(path) =>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is jrt is modified? We are dropping that information here and this can lead to undercompilations

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I asked that on discord and Eugene is not even sure if jrt is handled correctly by zinc. Anyways, this a deprecated API and I have no idea if we can get file from it (I tried)

@tgodzik
Copy link
Contributor Author

tgodzik commented Jan 31, 2022

I am a bit worried about tons of allocations we introduce with all this Path / FIle >=> VirtualFile conversions. I guess we would need to profile the bloop to see how much of the effect it will have.

I run the benchmarks and I haven't seen any impact, but I can try and minimize the conversions even further ( tried to do it as much as possible)

@romanowski
Copy link

if there is no regression then it can stay at it is. Let's merge it and optimize it when needed.

@tgodzik tgodzik force-pushed the update-newest-zinc branch from f0a70df to 611e39f Compare February 2, 2022 19:56
This was referenced Feb 15, 2022
In order to make upgrading versions easier we decided to switch back to sbt/zinc instead of a custom fork. The original reason for using the fork was to enable build pipelining, but that itself has been implemented in the orginal fork.

Unfortunately, to make the migration easier we needed to remove build pipelining for now to later add it with the default mechanism.

Related to scalacenter#1383

The benchmarks are being run to make sure we are not regressing in performance.
Biggest changes required here involved the new VirtualFile interface as we needed to convert them to java.io.File in a number of places. I tried to keep the conversions to a minimum, so that we don't bump into unexpected things such as issues with `jrt` filesystem and tried using Path wherever possible. I am not 100% if everything is correct, but I double checked and everything seems in place.

We also needed to adjust ScalaInstance to make it work with the new interface and add an additional setting for output in the Java compilers, since otherwise everything gets produced to source directories (this mirrors the change in zinc itself.)
@tgodzik
Copy link
Contributor Author

tgodzik commented Feb 21, 2022

The failures are unrelated, seems after windows being bumped the tests started failing.

@tgodzik tgodzik merged commit 7f377e9 into scalacenter:master Feb 21, 2022
@tgodzik tgodzik deleted the update-newest-zinc branch February 21, 2022 08:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants