Construction of Scala providers was already properly synchronized jvm and machine-wide.
The cache on top of construction was not and neither was the newer ClassLoaderCache.
This could cause the same Scala version to be loaded in multiple class loaders, taking
up more permgen space and possibly decreasing performance due to less effective jit.
The issue is very rare in practice for 0.13 because of the low probability of contention
on ClassLoaderCache. This is because the work for a cache miss is mainly the construction
of a URLClassLoader. In 0.12, however, the work potentially involved network access and
class loading (not just class loader construction), thus greatly increasing the probability
of contention and thus duplicate work (i.e. class loader construction).
When there is contention, multiple class loaders are constructed and then preserved by the
scalaInstance task in each project throughout the first task execution. Only when multiple
scalaInstance tasks execute simultaneously and only during the first execution does this occur.
(Technically, it could still happen later, but it doesn't in practice.)
This means that the number of duplicate class loaders should quickly saturate instead of growing
linearly with the number of projects. It also means that the impact depends on the exact
tree structure of projects. A linear chain of dependencies will be unaffected, but a build with
independent leaves may be limited by the number of cores. The number of cores affects
the number of threads typically used by the task engine, which limits the number of concurrently
executing scalaInstance tasks.
In summary, this might affect the first, cold compilation of a multi-module project with
independent leaves on a multi-core machine with Scala version different from the version used
for sbt. It might increase the maximum permgen requirements as well as slow the jit compilation
by up to one task execution. Subsequent compilations should be unaffected and the permgen
utilization return to be as expected.
The reported issue was a JLine class not being found on sbt startup.
JLine was depended on in the sbt build in two places, one with an extra
attribute (component) and one without. The retrieve pattern used by the
launcher includes that extra attribute. Previously, the dependency
without the attribute was selected and jline properly ended up on the sbt
classpath. Now, either by bumping JLine to 2.11 or some other
insignificant change, jline ends up in a subdirectory for the component
and doesn't get on the classpath.
(The move in 0.10 away from retrieving based on patterns and
using things directly from the cache was good, but this can't be
used in the launcher until a hash-based artifact is used so that
sbt+Scala jars aren't deleted or overwritten while sbt runs.)
A secondary issue was that the compiler-interface-src artifact didn't have
a configuration and was therefore not included in the published artifacts.
It is no longer necessary for it to be loaded in a stable class loader
and line reading in the launcher does not require anything more advanced
than java.io.Console.readLine(String).
Scala versions 2.8 and later use the version that goes through JAnsi
and for that it is sufficient to have JNA in a stable loader.
Needed an explicit type in PMap to workaround an error.
Need to drop tuple assignment of parser.parsed in input task macro as a workaround
for macro/resetAllAttrs/pattern matching/annotation issue in RC1.
All of `sbtVersion`, `defScalaVersion` and `buildScalaVersions` were
not used anymore. According to @harrah they are coming from really
old days of sbt and are not needed because of changes to how sbt
interacts with different Scala versions.
1. KList[M[_]] now instead of KList[HL <: HList, M[_]]
a. head, tail work properly in this variant
b. disadvantage is that full type not easily transformed to new type constructor
2. AList abstracts on K[L[x]], a higher order type constructor.
A. Instances written for:
a. KList
b. Seq[M[T]] for a fixed T
c. TupleN
d. single values
e. operate on one type constructor when nested
B. Main disadvantage is type inference. It just doesn't happen for K[L[x]].
This is mitigated by AList being used internally and rarely needing to construct a K.
* split several source files
* move base settings sources (Scope, Structure, ...) into main/settings/
* breaks cycles. In particular, setting system moved from Project to Def
Mark Harrah
cheeseng
Eugene Yokota
Paolo G. Giarrusso
Grzegorz Kossakowski
Eugene Vigdorchik