I noticed a long time ago that calls to def annotations in Symbols
figured way, way too high in profiling output, but my earlier efforts to
modify it failed because I didn't understand the "accidental" service
it was supplying. Here is the key piece of the former implementation of
annotations:
- val annots1 = initialize.rawannots map {
- case x: LazyAnnotationInfo => x.annot()
- case x: AnnotationInfo => x
- } filterNot (_.atp.isError)
The first thing you might notice is that because it calls initialize,
any call to either annotations or (more frequently) a method like
"hasAnnotation" causes a symbol to be initialized. The upshot is that
taking away tens of thousands of calls to initialize means a certain
amount of "free lunch" is over.
The second thing is that this implementation lead to the allocation of
a new list on every call to annotations. 99.999% of the time it's the
same elements in the list. The fact that rawannots is typed as a list of
"AnnotationInfoBase" which may as well be AnyRef means you can't even
use mapConserve, but even mapConserve would be an abuse of the garbage
collector given how infrequently there is any change.
So here's what we have now:
1) Annotations are delivered from trees to symbols by way of an
externally positioned map, not a field on the symbol. It's done once.
The only overhead on a call to annotations now is a null check.
2) I added a small sprinkling of calls to initialize in sensible
locations.
3) The profiler impact is hard to believe, but this is reproducible.
For whatever reason the non-profiler wall clock time impact is not
as impressive.
My profiling target was the compilation of these 15 files:
src/library/scala/collection/generic/G*.scala
Before this patch, heap usage peaked at 60MB. After, 35MB. 40% drop in
profiler measured time elapsed. (Again, it's not like that outside the
profiler.) About a 55% drop in number of allocations. About a 40% drop
in total size of allocations.
+----------------------+------------------+-----------------+-----------------+
| Name | Time Diff (ms) | Old Time (ms) | New Time (ms) |
+----------------------+------------------+-----------------+-----------------+
| +---<All threads> | -19,569 | 52,496 | 32,926 |
+----------------------+------------------+-----------------+-----------------+
+----------------------------+--------------------+-----------------------+
| Packages and Classes | Objects (+/-) | Size (+/-) |
+----------------------------+--------------------+-----------------------+
| +---<Objects by classes> | -877,387 -56 % | -26,425,512 -37 % |
| | | | |
| +---char[] | -43,308 -2 % | -2,756,744 -3 % |
| | | | |
| +---java | -67,064 -3 % | -2,027,264 -2 % |
| | | | |
| +---scala | -745,099 -48 % | -19,021,760 -26 % |
+----------------------------+--------------------+-----------------------+
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26042 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
If you run a jar directly, like
scala foo.jar
Then if a Class-Path attribute is present in the jar manifest, the
classpath will be constructed from that instead of the arguments. Some
things remain to be determined, like whether it's supposed to replace
a classpath given on the command line or supplement it, and whether
the master jar should be on the classpath or only and exactly the jars
listed in the manifest.
There's a really nice test case, which won't be run of course, but I
can't stand going any further without tests for these hard to test on
all platforms things. The faux .check file shows what I see.
Closes SI-4355, review by harrah.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26041 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Closes SI-1510 which is actually caused by a bad command line string when the path to Java contains a space, and not by long path names per se. References SI-622 since this commit fixes the specific error described there (not closing because follow-up bugs remain).
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26040 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
The complete histogram of results for "commonOwner" until this
patch, when building quick.lib and quick.comp:
Calculated common owner Occurrences
----------------------- -----------
NoSymbol 299,242
Everything Else 0
Since I'm always paranoid somebody will think I'm the one who
broke such things in the first place, I got in the gitmobile and
fingered the responsible party.
Looks OK when it was checked in: r3930, Feb 4 2005. And it was smooth
sailing until... r4026, Mar 22 2005. So 6 1/2 weeks of goodness for poor
commonOwnerMap, to be followed by 6 1/2 years of endless NoSymboldom. In
2005 I was still making a living grifting strangers in seedy gambling
halls, so I think I'm in the clear. Here's the exact spot.
ae0da87d1a (L12L991)
I found this while trying to figure out why we are generating so many
refinements. This doesn't fix any of that, but maybe takes us a notch
closer. Review by odersky.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26038 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
providing a richer TreeMakers interface in hopes of performing analyses and optimizations on TreeMakers rather than the trees they generate
not sure yet, though: on the one hand, working on raw trees removes the unsoundness potential due to the extra indirection layer
on the other hand, indirection is nice, and recovering the meaning lost in translation from richer treemakers to raw trees is such a drag
no review
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26036 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
farewell ProtoTreeMaker, we hardly knew ye
needed one more repeatedToSeq for pos/annotDepMethType when compiling under -Xexperimental and -Yvirtpatmat... I wonder why this hadn't failed before
outer check for extractor type test: definitely need it for case classes, and probably makes sense for user-defined extractors as well
no review
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26034 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
There's every hint that it's a requirement that a TypeApply have
non-empty typeArgs, but testing for and handling the empty condition
is done irregularly. Made a mkTypeApply which handles the isEmpty case
(returning "fun" unchanged.) Also unified most of the variations of
casts under one umbrella. Review by moors.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26033 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Painstakingly winnowed out the most frequently duplicated code
sequences related to symbol cloning and substitution. Created
canonical methods to perform these actions and documented them.
Key methods include:
def createFromClonedSymbols[T](syms: List[Symbol], tpe: Type)(creator: (List[Symbol], Type) => T): T
def deriveSymbols(syms: List[Symbol], symFn: Symbol => Symbol): List[Symbol]
def deriveType(syms: List[Symbol], symFn: Symbol => Symbol)(tpe: Type): Type
Many example usages enclosed with commit.
I did lots of timing tests, I find no material difference before and
after. Actually I won by four seconds in this incarnation:
Before - Total time: 7 minutes 55 seconds
After - Total time: 7 minutes 51 seconds
Review by moors.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26032 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Many thanks to Jordi Salvat i Alabart for catching this.
Universal equality is a formidable foe when it comes to avoiding
this kind of mistake. Closes SI-5206, no review.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26031 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
(The original commit in r26026, reverted in r26027, used the new compilerargs
element in the Scala build -- we cannot do this until it's in starr.)
- Revert r25995 which was fixing it only partly and in the wrong place.
- Properly encode argument files for scalac in scalac ant task.
- Allow 'compilerarg' elements in scalac ant task (like in ant's built-in
javac task) to allow passing extra parameters like plugindir path with
proper encoding of spaces and file names.
- Fix space handling in get-scala-revision.bat.
Closes SI-3047.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26030 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
This reverts the previous commit due to failure to build:
BUILD FAILED
/scratch/trunk1/build.xml:639: scalacfork doesn't support the nested "compilerarg" element.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26027 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Revert r25995 which was fixing it only partly and in the wrong place.
Properly encode argument files for scalac in scalac ant task.
Allow 'compilerarg' elements in scalac ant task (like in ant's built-in
javac task) to allow passing extra parameters like plugindir path with
proper encoding of spaces and file names, and use it in the Scala build.
Fix space handling in get-scala-revision.bat.
(Patch by Stefan Zeiger.) Closes SI-3047.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26026 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
scalac (ant.Scalac)
- added attributes `dependencyfile`, `explaintypes`, `nobootcp`,
`nowarn` and `usejavacp`
- added support for nested element `compilerarg` (see Ant manual)
in order to pass prefix settings (eg. -J-Xbootclasspath, -Ddebug=true)
to nsc.CompileClient
- updated list of permissible values for compiler phases
fsc (ant.FastScalac)
- added attributes `ip4` and `maxIdle` in addition to `reset`, `server`
and `shutdown` (and forwards them to nsc.CompileClient)
- also forwards prefix settings `jvmargs` and `defines`, and
boolean settings `explaintypes`, `nospecialization`, `nowarn`,
`optimise`, `unchecked` and `usejavacp` to nsc.CompileClient
- fixed CompileClient.process if-test
Nota Bene
I added the following element to partest.PartestTask (commit is pending)
in order to automatically test the Scala Ant tasks:
<anttests dir="${partest.dir}/${partest.srcdir}/ant" includes="*build.xml"/>
Here is the output:
[user@localhost scala]$ ant test.ant
Buildfile: /home/user/workspace/scala/build.xml
[echo] Forking with JVM opts: -Xms1536M [...]
init:
[echo] Build number is '2.10.0.r26022-b20111116212958'
[echo] Built 16 November 2011, 21:29:58 [...]
[...]
test.ant:
[partest] Running ant task tests
[partest] testing: [...]/files/ant/fsc-build.xml [ OK ]
[partest] testing: [...]/files/ant/scaladoc-build.xml [ OK ]
[partest] testing: [...]/files/ant/scalac-build.xml [ OK ]
[partest] Test suite finished with no failures.
BUILD SUCCESSFUL
Total time: 12 seconds
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26023 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
i think it couldn't find javac, since it was hardwired to JAVAHOME/bin/javac, but that didn't exist in the windows jre/ directory structure
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26020 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
printing an error instead of crashing the compiler. However, the unpickler has two more lazy types that crash
and stop the compiler if, on completion, it encounters a reference to a missing class file.
Since the SymbolTable has no way of reporting an error, we convert the MissingRequirementError in TypeErrors. This has the benefit of being printed nicely by the type checker (with a position where the type was needed).
This fixes extremely worrying behavior in the IDE when the class path is incomplete (for instance, after a rebuild with compilation errors).
review by odersky, extempore.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26012 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
contemplating the demise of ProtoTreeMaker, could TreeMaker be all we need?
no review, but with apologies if this generates merge conflicts for those exhausting themselves
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26010 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
don't need to re-type to the original type for correctness
(was more to verify the substitution was indeed type-preserving whenever possibly)
no review
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26009 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
ran into NPEs while running the test suite using the virtpatmat compiler,
decided it might happen to others
thus undertook to shield said others from sad NPEs
no review
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26007 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
also, moving more codegen out of translation and into codegen
in preparation of making codegen suitable for analysis
no review, though I'm sure extempore will be all over this
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26004 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
"Fiddle with lubs and glbs by never considering getClass as a member in
a refinement generated from them. In a sense we have justification for
this by saying we already treated getClass in an ad-hoc way, so we might
as well go all the way." -- m. odersky
Closes SI-4846.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@26001 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Removed assumption that bash is in /bin. Removed --posix option to bash.
Modernized shell constructs: $() instead of ``, [[ ]] instead of [ ].
Added -debug option for all runners which will show you the exact java
command line being run before running it. Added -usebootcp to complement
-nobootcp, and made regular classpath the default on cygwin. Quoted more
things to give us a fighting chance against spaces and parens in paths.
I took the waste-half-a-day step of installing vmware fusion so I could
install windows so I could install cygwin so I could install scala under
cygwin so I could see if it still worked. Seems to. We still desperately
need some way of testing not only everything I'm attempting to address
in this pile of patches but everything which is most likely now regressing.
:javap now sort of works on windows (not for repl-defined classes as yet)
if JAVA_HOME is set such that I can find tools.jar. Closes SI-4959.
(Risks breaking and) references SI-2092. References SI-622 since that
shouldn't be hard to get working.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25994 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
There's no way to ever correctly check against a platform
String and then fail if it doesn't exactly match. You have
to handle such things gracefully, because even if you have
omniscience and omnipotence at the time you write it, you will
become wrong later.
// example of a condition a vast distance from what should
// be tested before intentionally failing
if "%OS%" NEQ "Windows_NT"
Closes SI-4800.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25993 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
extempore