Previously: when a generation (say 2) is collected,
everything in gen 0 moves to gen 1
everything in gen 1 moves to gen 2
everything in gen 2 moves to gen 3
Now: when a generation (say 2 again) is collected
everything in gen 0 moves to gen 3
everything in gen 1 moves to gen 3
everything in gen 2 moves to gen 3
So, some objects get a leap from young to old if they're lucky to be
in the right time.
Consequences: when an object is moved by the collector, we don't
need to track old->new pointers and masks because all moved objects
are clean now. This both simplifies the collector and makes it more
efficient and might open the door for further optimization
opportunities. For bootstrap time, we get about 5% overall
saving and about 20% GC-time saving. Not bad.
BEFORE:
running stats for macro expansion:
45 collections
2558 ms elapsed cpu time, including 212 ms collecting
2576 ms elapsed real time, including 216 ms collecting
186972152 bytes allocated
running stats for code generation and serialization:
86 collections
4365 ms elapsed cpu time, including 1444 ms collecting
4374 ms elapsed real time, including 1449 ms collecting
362819096 bytes allocated
running stats for the entire bootstrap process:
131 collections
6928 ms elapsed cpu time, including 1657 ms collecting
6953 ms elapsed real time, including 1666 ms collecting
549818232 bytes allocated
AFTER:
running stats for macro expansion:
45 collections
2506 ms elapsed cpu time, including 169 ms collecting
2511 ms elapsed real time, including 171 ms collecting
186968056 bytes allocated
running stats for code generation and serialization:
86 collections
4083 ms elapsed cpu time, including 1189 ms collecting
4085 ms elapsed real time, including 1191 ms collecting
362810904 bytes allocated
running stats for the entire bootstrap process:
131 collections
6591 ms elapsed cpu time, including 1359 ms collecting
6599 ms elapsed real time, including 1362 ms collecting
549805944 bytes allocated
Happy Happy Joy Joy
|
||
|---|---|---|
| benchmarks | ||
| benchmarks.larceny | ||
| doc | ||
| lab | ||
| lib | ||
| other-libs | ||
| scheme | ||
| src | ||
| .bzrignore | ||
| ACKNOWLEDGMENTS | ||
| BUGS | ||
| COPYING | ||
| DEDICATIONS | ||
| GPL-3 | ||
| HOWTO-Contribute | ||
| Makefile.am | ||
| Makefile.in | ||
| README | ||
| aclocal.m4 | ||
| compile | ||
| config.guess | ||
| config.h.in | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| depcomp | ||
| install-sh | ||
| missing | ||
| mkinstalldirs | ||
README
Ikarus Scheme is an implementation of the Scheme programming language. The preliminary release of Ikarus implements the majority of the features found in the current standard, the Revised 6 report on the algorithmic language Scheme including full R6RS library and script syntax, syntax-case, unicode strings, bytevectors, user-defined record types, exception handling, conditions, and enumerations. Over 80% of the R6RS procedures and keywords are currently implemented and subsequent releases will proceed towards brining Ikarus to full R6RS conformance. The main purpose behind releasing Ikarus early is to give Scheme programmers the opportunity to experiment with the various new features that were newly introduced in R6RS. The most important of such features is the ability to structure large programs into libraries; where each library extends the language through procedural and syntactic abstractions. Many useful libraries can be written using the currently supported set of R6RS features including text processing tools, symbolic logic systems, interpreters and compilers, and many mathematical and scientific packages. It is my hope that this release will encourage the Scheme community to write and to share their most useful R6RS libraries.