Abdulaziz Ghuloum 372c3e369b Change of strategy in the garbage collector.
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
2007-12-15 10:43:29 -05:00
2007-11-19 19:04:10 -05:00
2007-10-25 17:43:40 -04:00
2007-10-25 17:43:40 -04:00
2007-11-19 19:04:10 -05:00
2007-12-01 21:38:16 -05:00
2007-10-25 17:43:40 -04:00
2007-10-25 17:43:40 -04:00
2007-10-25 17:43:40 -04:00
2007-10-31 04:43:22 -04:00

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.
S
Description
Ikarus Scheme (Bazaar checkout)
Readme
790 MiB
Languages
Scheme 87.1%
C 6.9%
TeX 2%
Makefile 1.3%
Shell 1.2%
Other 1.4%