Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Commit [be428f] Maximize Restore History

0.9.3.8.gc.1:

A bunch of GC changes that started to suffer from bitrot
before getting sufficiently mature to commit to HEAD. This
forward port to 0.9.3 seems to work, but hasn't been
properly tested.

The eventual goal of this branch is to have improved GC
latency, higher whole-system performance and

Currently done:

* The static space is a bad idea on gencgc, since it has no
write barrier. Make s-l-a-d default to not purifying on
gencgc.
* When loading a core, move the contents of the initial dynamic
space into the oldest generation.
* Allow doing the bits of purification related to manipulating
the info environment without doing a full purification. The
interface for this needs rethinking. Maybe always do the
compacting when s-l-a-d is called with :purify nil.
* Most iterations over the page table are only interested
in pages of one generation. After the static space has been
eliminated this becomes the major bottleneck in GC speed.
To speed this up, maintain a doubly linked list of the pages
in each generation.
* Abstract iterating over the page table with C macros.
* Make MAP-ALLOCATED-OBJECTS take advantage of the page table
on gencgc, for better performance and more accuracy.
* When saving a core without purification, do a
non-conservative GC.
* Add some typedefs for GC stuff like page table / generation
table indices, and try to use these types consistently
throughout the gencgc.
* Some misc. x86-64 cleanups.

To be done before this is fit for HEAD:
* Even though the s-l-a-d non-conservative GC is as efficient
at clearing out the unwanted bits as purify, it doesn't
properly compact memory. The core files are therefore about
two times bigger than they should be. Something clever needs
to be done here.
* Merge some bits from another tree that replaces the current
"munmap/mmap to zero pages lazily when GC frees them" behaviour
with "memset when pages are allocated to newspace". This might
be controversial.
* Test on x86.
* Check that the linked list manipulations are thread-safe.
* Rethink the changes to the purification interface.

Juho Snellman Juho Snellman 2005-07-28

changed src/code/gc.lisp
changed src/code/purify.lisp
changed src/code/room.lisp
changed src/code/save.lisp
changed src/compiler/x86-64/parms.lisp
changed src/compiler/x86/parms.lisp
changed src/runtime/gencgc-alloc-region.h
changed src/runtime/gencgc-internal.h
changed src/runtime/gencgc.c
changed src/runtime/save.c
changed src/runtime/save.h
changed make-target-2.sh
changed version.lisp-expr
src/code/gc.lisp Diff Switch to side-by-side view
Loading...
src/code/purify.lisp Diff Switch to side-by-side view
Loading...
src/code/room.lisp Diff Switch to side-by-side view
Loading...
src/code/save.lisp Diff Switch to side-by-side view
Loading...
src/compiler/x86-64/parms.lisp Diff Switch to side-by-side view
Loading...
src/compiler/x86/parms.lisp Diff Switch to side-by-side view
Loading...
src/runtime/gencgc-alloc-region.h Diff Switch to side-by-side view
Loading...
src/runtime/gencgc-internal.h Diff Switch to side-by-side view
Loading...
src/runtime/gencgc.c Diff Switch to side-by-side view
Loading...
src/runtime/save.c Diff Switch to side-by-side view
Loading...
src/runtime/save.h Diff Switch to side-by-side view
Loading...
make-target-2.sh Diff Switch to side-by-side view
Loading...
version.lisp-expr Diff Switch to side-by-side view
Loading...