| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Generalized a pile of duplicated type caching code, but it's still
largely undeployed because I haven't figured out how to make it as fast
as the copy-pasted version, which bugs me like you wouldn't believe.
Cannot deal with making "Sophie's Choice" between performance and lack
of duplication. I left one deployment in because it fixed a bug, or at
least so I see it: can't see why one would want the two absent error
messages in t2641.check. Review by odersky.
|
|
|
|
|
|
|
|
| |
A very conservative extraction of some of the FOOmode logic because it
lends itself to encapsulation and that's something we need more of. I am
doing everything these days with spectacularly high performance paranoia
so you don't even need to ask. (It is if anything faster.) No review.
|
| |
|
|
|
|
|
|
| |
Changed the cache in the jvm backend to use a WeakHashMap for names.
Added some details to mutable.WeakHashMap scaladoc.
|
|
|
|
|
|
| |
Remove symbols from the cache once they have been used to retrieve the
corresponding definition tree. no review.
|
|
|
|
|
|
| |
Modified the self-type protected accessor test to avoid unnecessary
runtime failures. Closes #4119, review by dragos.
|
|
|
|
|
|
|
|
|
|
| |
Investigating what can be done about our 2000 or so closures created
via by-name calls takes me through uncurry with a mop. Sifting through
compiler generated classfiles I am horrified at one example of decadent
closure creation perpetrated by a certain extempore. CompilerCommand
goes from 28 classfiles to 16 and manages to get smaller anyway anyway.
Some people just can't be trusted with closures. No review.
|
|
|
|
|
|
|
|
|
| |
There's still some temporary scaffolding propping up the Names
situation. This removes one strut: no more is there an implicit
conversion from String to TypeName. Implicits which remain to be deal
with: String => TermName, Name => TermName, Name => TypeName. Once
they're gone we're ready for KindNames! Just kidding, no review.
|
|
|
|
|
|
| |
Poking around at and hardening anything which may conceivably interact
with ZipFile.getNextEntry. No review.
|
|
|
|
|
|
| |
The above issue was made explicit using the dx tool for the Android SDK
to convert Java bytecode to Dalvik bytecode.
|
|
|
|
|
|
|
|
|
| |
Tired of paying the DEVIRTUALIZE compilation price, not to mention
checks for conditions which are never true, I disabled it more
thoroughly. Found a couple unused fields in expensive places like
Symbol. Stomped out some duplicate logic in the world of flattening and
places beyond. No review.
|
| |
|
|
|
|
|
|
| |
Some accumulated cleanup done while profiling and reducing uses of
length. No review.
|
|
|
|
|
|
|
|
| |
After profiling revealed 100Ks of unnecessary singleTypes being created,
I tracked it down to typeOfThis on ClassSymbol. I put in a cache like
the one on thisType and knocked almost 5% off the quick.comp time.
Review by odersky.
|
|
|
|
|
|
| |
Added withFilter to the list of monadic method names: otherwise the
inliner doesn't recognize its attractiveness. No review.
|
|
|
|
|
|
|
|
|
|
| |
down the long and freezy road once again. With this patch you can send a
SIGHUP to partest and it will spew a bunch of internal state. It is also
possible I fixed the underlying issue by cleaning up the super fragile
dependence on counters never getting the least bit off track. If fixed,
it'll still be fun to send signals. If not, this will be coming in handy
reeeeeal soon. No review.
|
|
|
|
|
|
|
|
| |
Some additions to SignalManager to make it easy to do things in response
to a signal. Like say if you're partest and you're back to freezing a
few times a day and you'd like to reveal what precisely you're up to. No
review.
|
|
|
|
|
| |
Plugging some leakiness I found in the pattern matcher. No review.
|
|
|
|
|
| |
stay for the aesthetics! Review by odersky.
|
|
|
|
|
|
|
| |
25% off the time spent in genjvm. Also eliminates the originalOwner
field in Symbol in favor of a cache which is only updated when the
originalOwner changes. Review by dragos.
|
|
|
|
|
|
| |
Looks like there is some side effecting I can't pin down. Reverts the
last two patches until my bring gets bigger. No review.
|
| |
|
|
|
|
|
|
| |
A couple caches knock a full 20% off the time spent in genjvm. Review by
dragos.
|
|
|
|
|
|
|
| |
Recognize calls to scala varargs methods where the parameter list is
empty, and give Nil as the sequence rather than wrapping an empty Array.
Review by odersky.
|
|
|
|
|
|
| |
Reinstantiated the "integrateNew" functionality under the suspicion that
this might solve some of the recent "tree not found" errors.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix 'Symbol.companionModule' for the resident mode compiler. It was
confused by having modules being translated to lazy values. The
direct consequence was a crash in the build manager when looking at a
constructor using a default argument (compiled separately), but only on
the second run.
The resident compiler may run many times over, and symbols may be
reused. Therefore, a module symbol that has been translated to a lazy
val by refchecks is not guaranteed to have MODULE set on the next run
(even before refcheck). Flags are not part of symbol history. Instead we
rely on the fact that a synthetic lazy value must have been a module.
review by odersky.
|
|
|
|
|
|
|
| |
This fixes a regression incurred in r23565 which was creating at least
tens of megabytes of garbage on each build. There is a whole bunch to
say about this one, but first the commit. Review by odersky.
|
|
|
|
|
|
|
| |
The undoLog is being cleared before a typer run, but not afterward. This
meant a huge amount of unnecessary garbage persisted beyond typer. Now,
more clearing. Review by moors.
|
|
|
|
|
| |
More elimination of avoidable calls to List#length. No review.
|
|
|
|
|
| |
Added settings for presentation compiler debugging options. no review.
|
|
|
|
|
|
| |
I really don't know the proper way to fix it in the current setting, so
just guarding.
|
|
|
|
|
| |
Quik fixes for - double definitions, - tree not found, - reloadSources
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is about not calling .length or .size on Lists. Sometimes it
is unavoidable; not often. I created some methods for the compiler which
should probably be in the collections, which do things like test if two
sequences have the same length in a more efficient manner than calling
length on each.
Also, wouldn't it be wonderful to have some mechanism for finding these
issues in a more automated way. Like say an annotation:
LinearSeqLike {
@badjuju("Calling length on linear seqs is O(n)")
def length: Int = whee
}
Or since I imagine everyone thinks they're calling length with lists of
2 or 3, an optional runtime check which yelled if it sees you calling
length on a 600 element list, or worse:
var i = 0
while (i < myList.length) { // you don't want to see what this does
f(myList(i)) ; i += 1;
}
Uniformity of interface without uniformity of behavior leaves us with
traps. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are constant distractions which I've meant forever to fix anyway, such
as the importing of collection.mutable._ (or any other package with lots
of reused names.) Why is this relevant to performance? Well,
var x = new HashSet[Int]
What's that? What does 'x += 1' mean? These are questions we can all
live without.
There's almost nothing left which references HashSet or HashMap or Stack
or other ambiguous classes without a qualifier: I can finish trunk but
I can't keep it clean on my own. (Where should I be writing this stuff
down, I wonder.) No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Explaining something for the (largeish N)th time finally awoke me to
the fact that software can explain things. I labored a long time over
this error message: I'm sure it can still use work (and/or it will drive
scalaz users off some kind of cliff) but the simple common case people
have so much trouble with is lit up like a christmas tree and for this I
will take some bullets.
build/pack/bin/scala -e 'class Foo[T] ; Set[Foo[AnyRef]]() + new
Foo[String]' :1: error: type mismatch; found : this.Foo[String]
required: this.Foo[java.lang.Object] Note: String <: java.lang.Object,
but class Foo is invariant in type T. You may wish to define T as +T
instead. (SLS 4.5) class Foo[T] ; Set[Foo[AnyRef]]() + new Foo[String]
^
Review by moors.
|
|
|
|
|
|
| |
into strings for the benefit of log messages which are never going to be
printed, that sort of thing. No review.
|
|
|
|
|
|
| |
One more insomniac try: the fix for -explaintypes having gone off the
deep end. Review by odersky.
|
|
|
|
|
| |
Reverting the previous patch for output change breakage. No review.
|
|
|
|
|
|
| |
The fix for -explaintypes having gone off the deep end. Perhaps other
good may come of it as well. Review by odersky.
|
|
|
|
|
|
| |
More fixes to avoid the dreaded "NoSymbol does not have owner" problem
in names defaults.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added some infrastructure for tracking and displaying information. Used
it to generate phase timing tables. Couldn't bring myself to add another
option so it's temporarily behind a system property until I sort out the
output options.
% scalac -Dscala.timings foo.scala
// or: ant -Djvm.opts="-Dscala.timings"
[...]
phase id ms share
-------------- -- ---- -----
typer 4 5816 44.94
mixin 20 1220 9.43
specialize 13 1179 9.11
erasure 15 916 7.08
...etc. No review.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Attempt to fix NoSymbol does not have owner problem in Eclipse.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
do not add entry in InnerClass attribute if outer name is null
(according to comment for outerName method) in order to remove the
following warning message reported by the dx tool (Android):
warning: Ignoring InnerClasses attribute for an anonymous inner class
(test$$anonfun$1) that doesn't come with an associated EnclosingMethod
attribute. This class was probably produced by a compiler that did
not target the modern .class file format. The recommended solution
is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of
ignoring this warning is that reflective operations on this class will
incorrectly indicate that it is *not* an inner class.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Removed the 'codeGenerator' field, which was a source of leaks.
Refactored javaName/javaType and the like. Now javaName does only name
mangling, and it is overriden by the BytecodeGenerator to keep track of
inner classes. JVMUtils now can be instantited by third party tools like
Eclipse and use javaName without polluting the code generator's state.
review by extempore.
|
| |
|