| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Fields: expand lazy vals during fields, like modules
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Essentially, we fuse mixin and lazyvals into the fields phase.
With fields mixing in trait members into subclasses, we
have all info needed to compute bitmaps, and thus we can
synthesize the synchronisation logic as well.
By doing this before erasure we get better signatures,
and before specialized means specialized lazy vals work now.
Mixins is now almost reduced to its essence: implementing
super accessors and forwarders. It still synthesizes
accessors for param accessors and early init trait vals.
Concretely, trait lazy vals are mixed into subclasses
with the needed synchronization logic in place, as do
lazy vals in classes and methods. Similarly, modules
are initialized using double checked locking.
Since the code to initialize a module is short,
we do not emit compute methods for modules (anymore).
For simplicity, local lazy vals do not get a compute method either.
The strange corner case of constant-typed final lazy vals
is resolved in favor of laziness, by no longer assigning
a constant type to a lazy val (see widenIfNecessary in namers).
If you explicitly ask for something lazy, you get laziness;
with the constant-typedness implicit, it yields to the
conflicting `lazy` modifier because it is explicit.
Co-Authored-By: Lukas Rytz <lukas@lightbend.com>
Fixes scala/scala-dev#133
Inspired by dotc, desugar a local `lazy val x = rhs` into
```
val x$lzy = new scala.runtime.LazyInt()
def x(): Int = {
x$lzy.synchronized {
if (!x$lzy.initialized) {
x$lzy.initialized = true
x$lzy.value = rhs
}
x$lzy.value
}
}
```
Note that the 2.11 decoding (into a local variable and a bitmap) also
creates boxes for local lazy vals, in fact two for each lazy val:
```
def f = {
lazy val x = 0
x
}
```
desugars to
```
public int f() {
IntRef x$lzy = IntRef.zero();
VolatileByteRef bitmap$0 = VolatileByteRef.create((byte)0);
return this.x$1(x$lzy, bitmap$0);
}
private final int x$lzycompute$1(IntRef x$lzy$1, VolatileByteRef bitmap$0$1) {
C c = this;
synchronized (c) {
if ((byte)(bitmap$0$1.elem & 1) == 0) {
x$lzy$1.elem = 0;
bitmap$0$1.elem = (byte)(bitmap$0$1.elem | 1);
}
return x$lzy$1.elem;
}
}
private final int x$1(IntRef x$lzy$1, VolatileByteRef bitmap$0$1) {
return (byte)(bitmap$0$1.elem & 1) == 0 ?
this.x$lzycompute$1(x$lzy$1, bitmap$0$1) : x$lzy$1.elem;
}
```
An additional problem with the above encoding is that the `lzycompute`
method synchronizes on `this`. In connection with the new lambda
encoding that no longer generates anonymous classes, captured lazy vals
no longer synchronize on the lambda object.
The new encoding solves this problem (scala/scala-dev#133)
by synchronizing on the lazy holder.
Currently, we don't exploit the fact that the initialized field
is `@volatile`, because it's not clear the performance is needed
for local lazy vals (as they are not contended, and as soon as
the VM warms up, biased locking should deal with that)
Note, be very very careful when moving to double-checked locking,
as this needs a different variation than the one we use for
class-member lazy vals. A read of a volatile field of a class
does not necessarily impart any knowledge about a "subsequent" read
of another non-volatile field of the same object. A pair of
volatile reads and write can be used to implement a lock, but it's
not clear if the complexity is worth an unproven performance gain.
(Once the performance gain is proven, let's change the encoding.)
- don't explicitly init bitmap in bytecode
- must apply method to () explicitly after uncurry
|
| |\ \
| | |
| | | |
SI-9823 Collections perf: favor virtual call over instanceof
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This avoids concurrent usages of collections in NUMA architectures
from falling of a performance cliff due to an implementation detail
of interface instanceof checks in HotSpot JVM.
The VM contains a one element cache in the metadata of each class
to record the most recent successful test for a interface.
For example:
classOf[Serializable].isAssignableFrom(classOf[Some[_]])
Would, in addition to returning `true`, set:
classOf[Some[_]]._secondary_super_cache = classOf[Serializable]
This is done to hide the fact that interface tests are O(N),
where N is the number of inherited interfaces.
This scheme is discussed in "Fast Subtype Checking for the
HotSpot JVM" (Click, Rose) [1]
However, if this cache repeatedly misses, not only are we
exposed to the linear search of the secondary super type array,
but we are also required to write back to the cache. If other
cores are operating on the same cache line, this can lead to
a significant slowdown ("cache thrashing"). This effect will
by most (or only?) visible on multi socket machines.
The pathological case is:
scala> Iterator.continually(List(classOf[Product], classOf[Serializable])).flatten.take(100).map(intf => intf.isAssignableFrom(classOf[Some[_]])).count(x => x)
res19: Int = 100
Which, if run on a multi-socket machine, should be much slower
than:
scala> (Iterator.continually(classOf[Product]).take(50) ++ Iterator.continually(classOf[Serializable]).take(50)).map(intf => intf.isAssignableFrom(classOf[Some[_]])).count(x => x)
res20: Int = 100
This commit avoids a interface test in a hot path in the collections
by instead using virtual dispatch to differentiate between
IndexedSeqLike and other collections. HotSpot will still use some
shared bookkeeping ("inline cache" [2]) at the callsites of
this method, but these stabilize in the megamorphic usage and no
longer force expensive cache line synchronization.
[1] https://www.researchgate.net/publication/221552851_Fast_subtype_checking_in_the_HotSpot_JVM
[2] https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
|
| |/
|
|
|
| |
Follow-up to remove the overloads, which is source
compatible, in favor of unapply(Any).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check for inheriting two conflicting members was wrong for default
methods, leading to a missing error message.
We were also not issuing "needs `override' modifier" when overriding a
default method.
Removes two methods:
- `isDeferredOrJavaDefault` had a single use that is removed in this commit.
- `isDeferredNotJavaDefault` is redundant with `isDeferred`, because
no default method has the `DEFERRED` flag:
- For symbols originating in the classfile parser this was the case
from day one: default methods don't receive the `DEFERRED` flag.
Only abstract interface methods do, as they have the `JAVA_ACC_ABSTRACT`
flag in bytecode, which the classfile parser translates to `DEFERRED`.
- For symbols created by the Java source parser, we don't add the
`DEFERRED` to default methods anymore since 373db1e.
Fixes scala/scala-dev#128
|
| |\
| |
| | |
SD-193 Lock down lambda deserialization
|
| | |
| |
| |
| |
| | |
- Remove unused references to "addTargetMethods"
- Require that `targetMethodMap` is provided
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The old design allowed a forged `SerializedLambda` to be
deserialized into a lambda that could call any private method
in the host class.
This commit passes through the list of all lambda impl methods
to the bootstrap method and verifies that you are deserializing
one of these.
The new test case shows that a forged lambda can no longer call
the private method, and that the new encoding is okay with a large
number of lambdas in a file.
We already have method handle constants in the constant pool
to support the invokedynamic through LambdaMetafactory, so
the only additional cost will be referring to these in
the boostrap args for `LambdaDeserialize`, 2 bytes per lambda.
I checked this with an example:
https://gist.github.com/retronym/e343d211f7536d06f1fef4b499a0a177
Fixes SD-193
|
| |\ \
| | |
| | | |
SI-7838 Document the multi-threading semantics of List and Vector
|
| | | |
| | |
| | |
| | | |
Making them completely thread-safe would be too expensive (in terms
of performance of single-threaded use cases).
|
| |\ \ \
| | | |
| | | | |
SI-8576 Minimal changes for `-Xcheckinit` compatibility
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As explained in https://issues.scala-lang.org/browse/SI-8576, I expect
serialization compatibility between builds with and without
`-Xcheckinit` to be unattainable. This commit contains some minor fixes
for issues discovered while running builds with `-Xcheckinit`:
- Add `@SerialVersionUID` to `scala.collection.immutable.Vector`, as
requested in SI-8576. Note that this does not make `Vector`
serialization compatible.
- Use lazy initialization for `global` in `PresentationCompilation`. It
used to access the uninitialized `self` variable (which seems to be
inconsequential in practice and only fails under `-Xcheckinit`).
We should consider using `Externalizable` instead of `Serializable` for
collections in 2.13 to make collection classes serialization compatible.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8434 Make generic Set operations build the same kind of Set
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When building from a `Set` implementation that was statically seen as
a `collection.GenSet` or `collection.Set`, we used to build a default
`Set` implementation determined by `GenSetFactory.setCanBuildFrom`.
This change modifies `setCanBuildFrom` to determine the correct
implementation at runtime by asking the source `Set`’s companion object
for the `Builder`.
Tests are in `NewBuilderTest.mapPreservesCollectionType`, including lots
of disabled tests for which I believe there is no solution under the
current collection library design.
`Map` suffers from the same problem as `Set`. This *can* be fixed in the
same way as for `Set` with some non-trivial changes (see the note in
`NewBuilderTest`), so it is probably best left for Scala 2.13.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-9019 TraversableLike stringPrefix broken for inner classes
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This version preserves outer class and object names but discards
any part of the name after a `$` that does not start with an upper-case
letter. When an integer literal occurs after a `$`, the prefix up to
that point is dropped so that classes defined within methods appear as
top-level.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-6881 Detect reference equality when comparing streams
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`==` already covers this case. We override `equals` in `Stream` to do
the same when `equals` is called directly. This takes care of identical
streams.
To support short-circuiting equality checks on elements prepended to
identical streams we also override `sameElements` in `Cons` to treat
the case where both sides are `Cons` separately.
Tests in StreamTest.test_reference_equality.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Introducing: the fields phase [ci: last-only]
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Derive/filter/propagate annotations in info transformer,
don't rely on having type checked the derived trees in order
to see the annotations.
Use synthetics mechanism for bean accessors -- the others
will soon follow.
Propagate inferred tpt from valdef to accessors
by setting type in right spot of synthetic tree
during the info completer.
No need to add trees in derivedTrees, and get rid of
some overfactoring in method synthesis, now that we have
joined symbol and tree creation.
Preserve symbol order because tests are sensitive to it.
Drop warning on potentially discarded annotations,
I don't think this warrants a warning.
Motivated by breaking the scala-js compiler, which relied
on annotations appearing when trees are type checked.
Now that ordering constraint is gone in the new encoding,
we may as well finally fix annotation assignment.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
One step towards teasing apart the mixin phase, making
each phase that adds members to traits responsible for
mixing in those members into subclasses of said traits.
Another design tenet is to not emit symbols or trees
only to later remove them. Therefore, we model a
val in a trait as its accessor. The underlying field
is an implementation detail. It must be mixed into
subclasses, but has no business in a trait (an interface).
Also trying to reduce tree creation by changing less in subtrees
during tree transforms.
A lot of nice fixes fall out from this rework:
- Correct bridges and more precise generic signatures for
mixed in accessors, since they are now created before erasure.
- Correct enclosing method attribute for classes nested in trait fields.
Trait fields are now created as MethodSymbol (no longer TermSymbol).
This symbol shows up in the `originalOwner` chain of a class declared
within the field initializer. This promoted the field getter to
being the enclosing method of the nested class, which it is not
(the EnclosingMethod attribute is a source-level property).
- Signature inference is now more similar between vals and defs
- No more field for constant-typed vals, or mixed in accessors
for subclasses. A constant val can be fully implemented in a trait.
TODO:
- give same treatment to trait lazy vals (only accessors, no fields)
- remove support for presuper vals in traits
(they don't have the right init semantics in traits anyway)
- lambdalift should emit accessors for captured vals in traits,
not a field
Assorted notes from the full git history before squashing below.
Unit-typed vals: don't suppress field
it affects the memory model -- even a write of unit to a field is relevant...
unit-typed lazy vals should never receive a field
this need was unmasked by test/files/run/t7843-jsr223-service.scala,
which no longer printed the output expected from the `0 to 10 foreach`
Use getter.referenced to track traitsetter
reify's toolbox compiler changes the name of the trait
that owns the accessor between fields and constructors (`$` suffix),
so that the trait setter cannot be found when doing mkAssign in constructors
this could be solved by creating the mkAssign tree immediately during fields
anyway, first experiment: use `referenced` now that fields runs closer
to the constructors phase (I tried this before and something broke)
Infer result type for `val`s, like we do for `def`s
The lack of result type inference caused pos/t6780 to fail
in the new field encoding for traits, as there is no separate accessor,
and method synthesis computes the type signature based on the ValDef tree.
This caused a cyclic error in implicit search, because now the
implicit val's result type was not inferred from the super member,
and inferring it from the RHS would cause implicit search to consider
the member in question, so that a cycle is detected and type checking fails...
Regardless of the new encoding, we should consistently infer result types
for `def`s and `val`s.
Removed test/files/run/t4287inferredMethodTypes.scala and test/files/presentation/t4287c,
since they were relying on inferring argument types from "overridden" constructors
in a test for range positions of default arguments. Constructors don't override,
so that was a mis-feature of -Yinfer-argument-types.
Had to slightly refactor test/files/presentation/doc, as it was relying
on scalac inferring a big intersection type to approximate the anonymous
class that's instantiated for `override lazy val analyzer`.
Now that we infer `Global` as the expected type based on the overridden val,
we make `getComment` private in navigating between good old Skylla and Charybdis.
I'm not sure why we need this restriction for anonymous classes though;
only structural calls are restricted in the way that we're trying to avoid.
The old behavior is maintained nder -Xsource:2.11.
Tests:
- test/files/{pos,neg}/val_infer.scala
- test/files/neg/val_sig_infer_match.scala
- test/files/neg/val_sig_infer_struct.scala
need NMT when inferring sig for accessor
Q: why are we calling valDefSig and not methodSig?
A: traits use defs for vals, but still use valDefSig...
keep accessor and field info in synch
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Also deprecate the TraitSetter annotation.
|
| |/ / / / / |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Typo fix in scala.sys.process.ProcessBuilder.
|
| | | |_|/ /
| |/| | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Fix race condition in lambda deserialization
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Review of the code made me aware that concurrent calls to
`$deserializeLambda$` for some lambda hosting class could result in
concurrent calls to operations on `j.u.HashMap`.
I've added a synchronized block to avoid this problem. I don't think
this is likely to be a bottleneck in practical use cases, but if so we
could come up with a lock-free scheme in the future.
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | | |
Reduce deprecations and warnings
|
| | | | | |
| | | | |
| | | | |
| | | | | |
... so we can make them private later.
|
| | |/ / / |
|
| |\ \ \ \
| |/ / /
|/| | | |
Improve Scaladoc for Either:
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
- remove text on projections
- add for comprehensions
|
| |\ \ \ \
| | | | |
| | | | | |
Override `.slice` in ArrayOps to use arraycopy.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This makes it ~10x faster when copying large chunks arround.
My benchmark:
def bm(duration: Long)(f: => Unit): Int = {
val end = System.currentTimeMillis + duration
var count = 0
while(System.currentTimeMillis < end) {
f
count += 1
}
count
}
def measure(seconds: Int)(f: => Unit) = (1 to seconds).map { _ => bm(1000)(f) }.sum / seconds
val array = scala.util.Random.alphanumeric.take(1000).toArray
measure(20) { array.slice(100, 500) }
// ~5 million
measure(20) { scala.collection.WrappedArray(array).slice(100, 500) }
// ~300K
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | | |
Deprecate @remote
|
| | | |_|/
| |/| | |
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8774 Null link fields in mutable LinkedHashMap (and friends) on remove
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Deprecate and rename Left#a/Right#b to Left#value/Right#value
|
| | | |_|_|/
| |/| | | |
|
| | |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Non specialized functions can directly use `scala.FunctionN` as the
functional interface, now that mixin generates default methods in
the new trait encoding.
Unfortunately we can't do this for specialized functions as things
stand: specialization leaves the wrong method abstract. In principle,
we could/should amend the specialization transform to fix this. But
my earlier attempts at this weren't sucessful, so for now we have
to stick with the fallback plan of keeping some hand rolled functional
interfaces around.
This commit reduces the surface area of `scala.runtime.java8` to
the minimal requiremnt: one functional interface for each specialized
variant of `Function{0,1,2}`.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-7301 Make tuple classes final
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | | |
This includes undoing the special case for `-Xfuture` introduced in
https://github.com/scala/scala/pull/2299 and updating tests to take
the new errors into account.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-9827 MatchIterator advances itself
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
To avoid caveats about calling `next` (or `hasNext`) before
using `MatchData` methods on `MatchIterator`, just do it
internally as necessary.
Note `MatchIterator` behavior in the docs.
Added tests showing what people cried about.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-6947 Better type parameter names for Map classes
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Type parameter names are currently assigned pretty much alphabetically
without any meaning. This change renames all key parameters in Map
classes from `A` to `K` and all value parameters from `B` to `V` to
make them more meaningful. Derived names are renamed accordingly (e.g.
`V1` instead of `B1` for an upper bound on `V`, `W` instead of `C` for
a new value type).
As a side-effect this solves the documentation problem in SI-6947. Due
to using `B` both as a type parameter for `foldLeft[B]` in
`GenTraversableOnce[A]` and in `Map[A, B]` which extends
`GenTraversableOnce[(A, B)]`, the signature of `Map.foldLeft` was
rendered in scaladoc as
def foldLeft[B](z: B)(op: (B, (A, B)) ⇒ B): B
Now you get an unambiguous version:
def foldLeft[B](z: B)(op: (B, (K, V)) ⇒ B): B
|
| |\ \ \ \
| | | | |
| | | | | |
Deprecated and rename Some#x to Some#value
|
