| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move run/t8960 to pending
It tests the serialVersionUID field on closure classes. The field
doesn't exist for indyLambda closures.
See https://issues.scala-lang.org/browse/SI-9373
Move some reify tests to pending
They fail at runtime in GenBCode since scala is built with indyLambda
enabled:
java.lang.AssertionError: assertion failed: Bad superClass for trait JFunction1: class Any
at scala.tools.nsc.Global.assert(Global.scala:261)
at scala.tools.nsc.backend.jvm.BTypesFromSymbols.setClassInfo(BTypesFromSymbols.scala:228)
Noted in https://issues.scala-lang.org/browse/SI-9374
force t6546 to GenASM - no closure elimination in GenBCode yet
Noted in https://issues.scala-lang.org/browse/SI-9364.
Fix or disable some tests that fail because of the old optimizer
The old inliner fails more often when the library is built with
indylambda.
Noted in https://issues.scala-lang.org/browse/SI-9374.
Example: List.foreach
➜ sandbox git:(jfun) ✗ qs -Ybackend:GenASM -optimize -Yinline-warnings
Welcome to Scala version 2.12.0-20150630-220939-1cb032d806 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_45).
Type in expressions to have them evaluated.
Type :help for more information.
scala> List(1,2,3).foreach(x => x + 1)
<console>:11: warning: Could not inline required method foreach because bytecode unavailable.
List(1,2,3).foreach(x => x + 1)
^
<console>:11: warning: At the end of the day, could not inline @inline-marked method foreach
List(1,2,3).foreach(x => x + 1)
^
Upate a number of tests for having indyLambda enabled
The delambdafyLambdaClassNames tests was removed, there's nothing to
tests with indyLambda.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e1895d64f87dc3c699a3ccbc8a3143b18d3b5bb1,
titled "Add scala-java8-compat to scala-library.jar".
Move SAM functions and `LambdaDeserializer` (from scala/scala-java8-compat@9253ed9)
into `scala.runtime.java8` package under `src/library`.
(The package name is the only diff -- they were in `scala.compat.java8` before).
The original LambdaDeserializer:
https://github.com/scala/scala-java8-compat/blob/c0732e6/src/main/java/scala/compat/java8/runtime/LambdaDeserializer.scala
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Java parser should not set the `DEFERRED` flag for
default methods or static methods in interfaces.
Their bytecode doesn't have it either.
Also tightens parsing of Java abstract methods to
disallow a method body.
Here's the log of how Lukas diagnosed this:
```
quick.bin:
...
BUILD FAILED
/Users/luc/scala/scala/build.xml:69: The following error occurred while executing this line:
...
/Users/luc/scala/scala/build-ant-macros.xml:350: Could not create type mk-bin due to
java.lang.BootstrapMethodError: call site initialization exception
at java.lang.invoke.CallSite.makeSite(CallSite.java:341)
at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307)
at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297)
at scala.sys.BooleanProp$.keyExists(BooleanProp.scala:72)
at scala.sys.SystemProperties$.bool(SystemProperties.scala:78)
at scala.sys.SystemProperties$.noTraceSupression$lzycompute(SystemProperties.scala:89)
at scala.sys.SystemProperties$.noTraceSupression(SystemProperties.scala:89)
at scala.util.control.NoStackTrace$.<init>(NoStackTrace.scala:31)
at scala.util.control.NoStackTrace$.<clinit>(NoStackTrace.scala)
at scala.util.control.NoStackTrace$class.fillInStackTrace(NoStackTrace.scala:22)
at scala.util.control.BreakControl.fillInStackTrace(Breaks.scala:94)
at java.lang.Throwable.<init>(Throwable.java:250)
at scala.util.control.BreakControl.<init>(Breaks.scala:94)
at scala.util.control.Breaks.<init>(Breaks.scala:29)
at scala.collection.Traversable$.<init>(Traversable.scala:95)
at scala.collection.Traversable$.<clinit>(Traversable.scala)
at scala.package$.<init>(package.scala:40)
at scala.package$.<clinit>(package.scala)
at scala.Predef$.<init>(Predef.scala:89)
at scala.Predef$.<clinit>(Predef.scala)
at scala.tools.ant.ScalaTool.<init>(ScalaTool.scala:58)
[...]
Caused by: java.lang.invoke.LambdaConversionException:
Incorrect number of parameters for static method invokeStatic
scala.sys.BooleanProp$.scala$sys$BooleanProp$$$anonfun$2$adapted:(String)Object;
0 captured parameters, 0 functional interface method parameters, 1 implementation parameters
at java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:193)
at java.lang.invoke.LambdaMetafactory.altMetafactory(LambdaMetafactory.java:473)
at java.lang.invoke.CallSite.makeSite(CallSite.java:325)
```
[source code](https://github.com/scala/scala/blob/2.11.x/src/library/scala/sys/BooleanProp.scala#L72):
```
s => s == "" || s.equalsIgnoreCase("true")
```
bytecode:
```
INVOKEDYNAMIC $init$()Lscala/compat/java8/JFunction1; [
// handle kind 0x6 : INVOKESTATIC
java/lang/invoke/LambdaMetafactory.altMetafactory(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
// arguments:
()V,
// handle kind 0x6 : INVOKESTATIC
scala/sys/BooleanProp$.scala$sys$BooleanProp$$$anonfun$2$adapted(Ljava/lang/String;)Ljava/lang/Object;,
(Ljava/lang/String;)Ljava/lang/Object;,
3,
1,
Lscala/Serializable;.class,
0
]
CHECKCAST scala/Function1
```
The mistake seems to be that the Scala compiler incorrectly selects `$init$`
([which is a default method](https://github.com/scala/scala/blob/640ffe7fceb5d573b2c12a7c7da09bfd751036a0/src/library/scala/compat/java8/JFunction1.java#L10))
as the abstract method of `JFunction1`, whereas it should be `apply` (inherited from `Function1`).
Since we're doing mixed compilation, this is almost certainly a problem of the Java parser.
|
|\
| |
| | |
Fix size update on `mutable.TreeMap#clear()`
|
| |
| |
| |
| |
| |
| | |
The previous implementation has a major bug - although `clear()` sets the root node to `null`, the `size` attribute of the `Tree` was not updated. This effectively meant that even after a `map.clear()`, a call to `map.size` would still yield the old size of the map.
The scalacheck test suite was updated to contemplate this issue.
|
|\ \
| |/
|/| |
|
| |\
| | |
| | | |
Fix 8 typos (j-l)
|
| | | |
|
| |\ \
| | |/
| |/| |
Closure elimination for new backend
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
ASM has a built-in `SourceValue` analysis which computes for each
value a set of instructions that may possibly have constructed it.
The ProdConsAnalyzer class provides additional queries over the
result of the SourceValue analysis:
- consumers of values
- tracking producers / consumers through copying operations (load,
store, etc)
A fix to (and therefore a new version of) ASM was required. See here:
https://github.com/scala/scala-asm/commit/94106a5472
|
| | |
| | |
| | |
| | | |
It was fixed in GenASM in 44807a7852.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Switch the defaults of `-Ydelambdafy` and `-Ybackend`.
Rewrite t6288b-jump-position test - no more icode
Don't crash GenBCode beyond JVM code size limits
A similar patch is in GenASM, see 3fa2c97
Fix check files for GenBCode / delambdafy:method defaults
Force copy propagation test to ASM, see SI-9364
Force inline-ex-handlers test to GenASM, see SI-9364
Move t6613 test to pending - still broken in GenBCode
Adding a `flags` file with `-Ybackend:GenASM` doesn't seem to have
the desired effect.
SI-6613 is re-opened.
Force a few tests to GenASM, see SI-9364
|
|\ \ \
| | | |
| | | | |
SI-9277 Downgrade marginal javap features
|
| | | |
| | | |
| | | |
| | | | |
Drop Java 6 support, -fun, -app, and -raw options.
|
|\ \ \ \
| | | | |
| | | | | |
SI-4147 Add an implementation of `mutable.TreeMap`
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commit contains an implementation of a mutable red-black tree with focus on performance. It also contains a new `mutable.TreeMap` Scala collection that is backed by the aforementioned tree. The common generic factories and traits related to mutable sorted maps didn't exist yet, so this commit also adds them.
Regarding performance, `TreeMap` overrides (from `MapLike` and `SortedMapLike`) all of the most common methods for maps and also those whose default implementations are asymptotically worse than direct red-black tree algorithms (e.g. `last`, `clear`).
The `rangeImpl` method of `TreeMap` returns an instance of `TreeMapView`, an inner class of `TreeMap`. This view is backed by the same `RedBlackTree.Tree` instance, and therefore changes to the original map are reflected in the view and vice-versa. The semantics of mutating a view by adding and removing keys outside the view's range are the same of the current `mutable.TreeSet`. A bit less focus was given on the performance of views - in particular, getting the `size` of a `TreeMapView` is O(n) on the number of elements inside the view bounds. That can be improved in the future.
In a future commit, `mutable.TreeSet` can be changed to be backed by this red-black tree implementation.
|
|\ \ \ \ \
| |_|/ / /
|/| | | | |
Documentation for split [ci: last-only]
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Reverts to calling String.split(re: String), but change escape to
always put us on the JDK7 fast-path if possible, which is for everything
but Chars representing surrogate codeunits
|
|\ \ \ \
| |/ / /
|/| / /
| |/ / |
|
| |\ \
| | | |
| | | | |
Fix 25 typos (g-i)
|
| | |/ |
|
| |\ \
| | | |
| | | | |
SI-9206 Fix REPL code indentation
|
| | | |
| | | |
| | | |
| | | | |
But sans test.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
To make code in error messages line up with the original line of
code, templated code is indented by the width of the prompt.
Use the raw prompt (without ANSI escapes or newlines) to determine
the indentation.
Also, indent only once per line.
|
| |\ \ \
| | |_|/
| |/| | |
SI-9359 Fix InnerClass entry flags for nested Java enums
|
| | | | |
|
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The access flags in InnerClass entries for nested Java enums were
basically completely off.
A first step is to use the recently introduced backend method
`javaClassfileFlags`, which is now moved to BCodeAsmCommon.
See its doc for an explanation.
Then the flags of the enum class symbol were off. An enum is
- final if none of its values has a class body
- abstract if it has an abstract method
(https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.9)
When using the ClassfileParser:
- ENUM was never added. I guess that's just an oversight.
- ABSTRACT (together with SEALED) was always added. This is to
enable exhaustiveness checking, see 3f7b8b5. This is a hack and we
have to go through the class members in the backend to find out if
the enum actually has the `ACC_ABSTRACT` flag or not.
When using the JavaParser:
- FINAL was never added.
- ABSTRACT was never added.
This commit fixes all of the above and tests cases (Java enum read
from the classfile and from source).
|
| |/ |
|
| |\
| | |
| | | |
Fix some typos (a-c)
|
| | |
| | |
| | |
| | |
| | |
| | | |
I just used text search to check whether there are no more typos like
these corrected by janekdb, and by the way fixed also some other ones
which I saw.
|
| | | |
|
| |\ \
| | |/
| |/| |
Fix illegal inlining of instructions accessing protected members
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There were two issues in the new inliner that would cause a
VerifyError and an IllegalAccessError.
First, an access to a public member of package protected class C can
only be inlined if the destination class can access C. This is tested
by t7582b.
Second, an access to a protected member requires the receiver object
to be a subtype of the class where the instruction is located. So
when inlining such an access, we need to know the type of the receiver
object - which we don't have. Therefore we don't inline in this case
for now. This can be fixed once we have a type propagation analyis.
https://github.com/scala-opt/scala/issues/13.
This case is tested by t2106.
Force kmpSliceSearch test to delambdafy:inline
See discussion on https://github.com/scala/scala/pull/4505. The issue
will go away when moving to indy-lambda.
|
| |\ \
| | | |
| | | | |
fix BigDecimal losing MathContext
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | | |
| | | | | |
SI-9356 more careful assertion in back-end
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Calling `exists` on a `Symbol` triggers unpickling,
which failed for reasons I did not investigate.
Replaced `sym.exists` by `sym != NoSymbol`, which is good enough here.
Also replaced assertion by a `devWarning`, since the
logic seems too ad-hoc to actually crash the compiler when it's invalidated.
Partially reverts b45a91fe22. See also #1532.
|
| |\ \ \ \
| | | | | |
| | | | | | |
SI-9348 Fix missing last element in exclusive floating point ranges
|
| | |/ / /
| | | | |
| | | | |
| | | | |
| | | | | |
Fix exclusive floating point ranges to contain also the last element
when the end-start difference is not an integer multiple of step.
|
| |\ \ \ \
| | |/ / /
| |/| | | |
Fix toolbox with varargs constructors
|
| | | | |
| | | | |
| | | | |
| | | | | |
It was already working for methods, but not for constructors.
|
| |\ \ \ \
| | | | | |
| | | | | | |
Clean implementation of sorts for scala.util.Sorting.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Removed code based on Sun JDK sorts and implemented new (basic) sorts from
scratch. Deferred to Java Arrays.sort whenever practical. Behavior of
`scala.util.Sorting` should be unchanged, but changed documentation to
specify when the Java methods are being used (as they're typically very fast).
A JUnit test is provided.
Performance is important for sorts. Everything is better with this patch,
though it could be better yet, as described below.
Below are sort times (in microseconds, SEM < 5%) for various 1024-element
arrays of small case classes that compare on an int field (quickSort), or
int arrays that use custom ordering (stableSort). Note: "degenerate"
means there are only 16 values possible, so there are lots of ties.
Times are all with fresh data (no re-using cache from run to run).
Results:
```
random sorted reverse degenerate big:64k tiny:16
Old Sorting.quickSort 234 181 178 103 25,700 1.4
New Sorting.quickSort 170 27 115 74 18,600 0.8
Old Sorting.stableSort 321 234 236 282 32,600 2.1
New Sorting.stableSort 239 16 194 194 25,100 1.2
java.util.Arrays.sort 124 4 8 105 13,500 0.8
java.util.Arrays.sort|Box 126 15 13 112 13,200 0.9
```
The new versions are uniformly faster, but uniformly slower than Java sorting. scala.util.Sorting has use cases that don't map easily in to Java unless everything is pre-boxed, but the overhead of pre-boxing is minimal compared to the sort.
A snapshot of some of my benchmarking code is below.
(Yes, lots of repeating myself--it's dangerous not to when trying to get
somewhat accurate benchmarks.)
```
import java.util.Arrays
import java.util.Comparator
import math.Ordering
import util.Sorting
import reflect.ClassTag
val th = ichi.bench.Thyme.warmed()
case class N(i: Int, j: Int) {}
val a = Array.fill(1024)( Array.tabulate(1024)(i => N(util.Random.nextInt, i)) )
var ai = 0
val b = Array.fill(1024)( Array.tabulate(1024)(i => N(i, i)) )
var bi = 0
val c = Array.fill(1024)( Array.tabulate(1024)(i => N(1024-i, i)) )
var ci = 0
val d = Array.fill(1024)( Array.tabulate(1024)(i => N(util.Random.nextInt(16), i)) )
var di = 0
val e = Array.fill(16)( Array.tabulate(65536)(i => N(util.Random.nextInt, i)) )
var ei = 0
val f = Array.fill(65535)( Array.tabulate(16)(i => N(util.Random.nextInt, i)) )
var fi = 0
val o = new Ordering[N]{ def compare(a: N, b: N) = if (a.i < b.i) -1 else if (a.i > b.i) 1 else 0 }
for (s <- Seq("one", "two", "three")) {
println(s)
th.pbench{ val x = a(ai).clone; ai = (ai+1)%a.length; Sorting.quickSort(x)(o); x(x.length/3) }
th.pbench{ val x = b(bi).clone; bi = (bi+1)%b.length; Sorting.quickSort(x)(o); x(x.length/3) }
th.pbench{ val x = c(ci).clone; ci = (ci+1)%c.length; Sorting.quickSort(x)(o); x(x.length/3) }
th.pbench{ val x = d(di).clone; di = (di+1)%d.length; Sorting.quickSort(x)(o); x(x.length/3) }
th.pbench{ val x = e(ei).clone; ei = (ei+1)%e.length; Sorting.quickSort(x)(o); x(x.length/3) }
th.pbench{ val x = f(fi).clone; fi = (fi+1)%f.length; Sorting.quickSort(x)(o); x(x.length/3) }
}
def ix(ns: Array[N]) = {
val is = new Array[Int](ns.length)
var i = 0
while (i < ns.length) {
is(i) = ns(i).i
i += 1
}
is
}
val p = new Ordering[Int]{ def compare(a: Int, b: Int) = if (a > b) 1 else if (a < b) -1 else 0 }
for (s <- Seq("one", "two", "three")) {
println(s)
val tag: ClassTag[Int] = implicitly[ClassTag[Int]]
th.pbench{ val x = ix(a(ai)); ai = (ai+1)%a.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
th.pbench{ val x = ix(b(bi)); bi = (bi+1)%b.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
th.pbench{ val x = ix(c(ci)); ci = (ci+1)%c.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
th.pbench{ val x = ix(d(di)); di = (di+1)%d.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
th.pbench{ val x = ix(e(ei)); ei = (ei+1)%e.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
th.pbench{ val x = ix(f(fi)); fi = (fi+1)%f.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
}
for (s <- Seq("one", "two", "three")) {
println(s)
th.pbench{ val x = a(ai).clone; ai = (ai+1)%a.length; Arrays.sort(x, o); x(x.length/3) }
th.pbench{ val x = b(bi).clone; bi = (bi+1)%b.length; Arrays.sort(x, o); x(x.length/3) }
th.pbench{ val x = c(ci).clone; ci = (ci+1)%c.length; Arrays.sort(x, o); x(x.length/3) }
th.pbench{ val x = d(di).clone; di = (di+1)%d.length; Arrays.sort(x, o); x(x.length/3) }
th.pbench{ val x = e(ei).clone; ei = (ei+1)%e.length; Arrays.sort(x, o); x(x.length/3) }
th.pbench{ val x = f(fi).clone; fi = (fi+1)%f.length; Arrays.sort(x, o); x(x.length/3) }
}
def bx(is: Array[Int]): Array[java.lang.Integer] = {
val Is = new Array[java.lang.Integer](is.length)
var i = 0
while (i < is.length) {
Is(i) = java.lang.Integer.valueOf(is(i))
i += 1
}
Is
}
def xb(Is: Array[java.lang.Integer]): Array[Int] = {
val is = new Array[Int](Is.length)
var i = 0
while (i < is.length) {
is(i) = Is(i).intValue
i += 1
}
is
}
val q = new Comparator[java.lang.Integer]{
def compare(a: java.lang.Integer, b: java.lang.Integer) = o.compare(a.intValue, b.intValue)
}
for (s <- Seq("one", "two", "three")) {
println(s)
val tag: ClassTag[Int] = implicitly[ClassTag[Int]]
th.pbench{ val x = bx(ix(a(ai))); ai = (ai+1)%a.length; Arrays.sort(x, q); xb(x)(x.length/3) }
th.pbench{ val x = bx(ix(b(bi))); bi = (bi+1)%b.length; Arrays.sort(x, q); xb(x)(x.length/3) }
th.pbench{ val x = bx(ix(c(ci))); ci = (ci+1)%c.length; Arrays.sort(x, q); xb(x)(x.length/3) }
th.pbench{ val x = bx(ix(d(di))); di = (di+1)%d.length; Arrays.sort(x, q); xb(x)(x.length/3) }
th.pbench{ val x = bx(ix(e(ei))); ei = (ei+1)%e.length; Arrays.sort(x, q); xb(x)(x.length/3) }
th.pbench{ val x = bx(ix(f(fi))); fi = (fi+1)%f.length; Arrays.sort(x, q); xb(x)(x.length/3) }
}
```
|
| |\ \ \ \ \
| | |_|/ / /
| |/| | | | |
SI-7747 Make REPL wrappers serialization friendly.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We only need to introduce the temporary val in the imports
wrapper when we are importing a val or module defined in the REPL.
The test case from the previous commit still passes, but
we are generating slightly simpler code.
Compared to 2.11.6, these two commits result in the following
diff:
https://gist.github.com/retronym/aa4bd3aeef1ab1b85fe9
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Spark has been shipping a forked version of our REPL for
sometime. We have been trying to fold the patches back into
the mainline so they can defork. This is the last outstanding
issue.
Consider this REPL session:
```
scala> val x = StdIn.readInt
scala> class A(a: Int)
scala> serializedAndExecuteRemotely {
() => new A(x)
}
```
As shown by the enclosed test, the REPL, even with the
Spark friendly option `-Yrepl-class-based`, will re-initialize
`x` on the remote system.
This test simulates this by running a REPL session, and then
deserializing the resulting closure into a fresh classloader
based on the class files generated by that session. Before this
patch, it printed "evaluating x" twice.
This is based on the Spark change described:
https://github.com/mesos/spark/pull/535#discussion_r3541925
A followup commit will avoid the `val lineN$read = ` part if we
import classes or type aliases only.
[Original commit from Prashant Sharma, test case from Jason Zaugg]
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
Nullness Analysis for GenBCode
|