guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

new GC code merged


From: Han-Wen
Subject: new GC code merged
Date: Sun, 4 Aug 2002 02:27:23 +0200

I merged my new GC code into HEAD. It's tagged before-hanwen-gc-change
and after-hanwen-gc-change. Here the preliminary notes for it. I'm not
sure what else you want me to document, but I think the current change
log entries are not verbose enough. Anyway, here goes:



CHANGES IN FUNCTIONALITY

The GC uses cards (2kb pages of cells) as the basic unit for
allocation. Cards are grouped together in heap segments, that hold a
collection of cards for a single type of cell (single or double).

Sweeping is done lazily: the freelist is short (between 0 and 512
cells), and every time it is empty, cards are swept until a new
freelist of 512 cells is collected. This has the following
consequences: unused cells typically contain real garbage (as opposed
to the freecell-tag), and the meaning of some statistics is changed a
little: for example, it is not possible to tell how many cells have
been marked right after a GC.

The reasoning behind lazy sweeping this is that it is more cache
friendly, and easier to extend to multithreaded apps.

All traces of clusters have been removed completely.

The debugging part has been changed. The mark bits are now used to
validate cell accesses: scm_newcell checks that each cell it hands out
has no mark bit set, and then sets it. scm_assert_cell_valid() checks
if a cell has a markbit. These checks are cheap, so they are turned on
if GUILE is compiled with --enable-debugging. When
(set-debug-cell-access! #t) is done, scm_in_heap_p() and GC at regular
intervals is done in addition.

Since the big freelists doesn't exist any longer, having debugging
support for it is pointless. I removed the routines for doing that.


When malloc wants to have more memory, it does a mark followed by a
full sweep. The behavior for scm_mtrigger has been changed to follow
that of the cell GC: two environment variables have been added,

  GUILE_INIT_MALLOC_LIMIT
  GUILE_MIN_YIELD_MALLOC

that are analogous to those for the cells. This significantly speeds
up the for example, the doc snarfing during a GUILE compile. (Note
that the old mechanism contained an unscaled parameter,
SCM_MTRIGGER_HYSTERESIS). Also, setting the malloc limit from 100k to
200k helps (after booting guile, there already is 100k malloced
memory.)


CHANGES IN FILE LAYOUT

The GC is now split across several files

* gc.c - global entry points, like gc-stats, scm_igc,

* gc-mark.c - code for doing marking. This contains the ghastly mark switch(){}

* gc-segment.c - dealing with heap segments (scm_t_heap_segment)

* gc-card.c - cards (pages) of memory. This contains the ghastly sweep 
switch(){}

* gc-freelist.c - code for scm_t_freelist

* private-gc.h - a header file containing definitions for code only
used by these modules

CHANGES IN API

The GC is in many ways mostly internal to GUILE, and it was not clear
which of the macros/functions/variables are to be considered internal
and external. As far as I'm concerned, no handholding for upgrading
should be provided (but hey, I'm a fascist developer :-)


REMOVED FROM <gc.h>

* SCM_CELLPTR - C already has syntax for declaring pointers:
                scm_t_cell *

* SCM_PTR_* - idem for comparisons.

* SCM_GC_CARD_N_DATA_CELLS

* SCM_GC_CELL_SPAN

* SCM_C_BVEC_BITS2BYTES

* SCM_C_BVEC_SET_BYTES

* SCM_C_BVEC_SET_ALL_BITS

* SCM_C_BVEC_CLR_BYTES

* SCM_C_BVEC_CLR_ALL_BITS

* SCM_FREECELL_P (using SCM_FREECELL_P introduces a compile error
  explaining why.)

* scm_heap_table, scm_n_heap_segs:  moved to private-gc.h


CHANGED NAME

* SCM_GCMARKP -> SCM_GC_MARK_P

* SCM_SETGCMARK -> SCM_SET_GC_MARK

* SCM_CLRGCMARK -> SCM_CLEAR_GC_MARK

* SCM_C_BVEC_CLR -> SCM_C_BVEC_CLEAR

* SCM_GC_CARD_SIZE -> SCM_GC_SIZEOF_CARD

* SCM_GC_CLR_CARD_FLAG(S) -> SCM_GC_CLEAR_CARD_FLAG(S)

* SCM_GC_CELL_CLR_BIT -> SCM_GC_CELL_CLEAR_BIT

* limb -> long

* scm_[master_]free_list[2] -> scm_i_[master_]freelist[2]

* scm_cellp -> scm_in_heap_p (to me the 2nd name is more clear, but I
don't think that is worth the trouble of providing deprecation
warnings).

* scm_t_freelist -> scm_t_cell_type_statistics

DEPRECATED:

        scm_default_init_heap_size_1;
        scm_default_min_yield_1;
        scm_default_init_heap_size_2;
        scm_default_min_yield_2;
        scm_default_max_segment_size;
        scm_map_free_list 
        scm_free_list_length
        scm_gc_set_debug_check_freelist_x 




-- 

Han-Wen Nienhuys   |   address@hidden   |   http://www.cs.uu.nl/~hanwen 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]