From: Han-Wen <hanwen@cs.uu.nl>
Subject: new GC code merged
Date: Sun, 4 Aug 2002 02:27:23 +0200 [thread overview]
Message-ID: <15692.29931.82055.847632@blauw.xs4all.nl> (raw)
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 | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next reply other threads:[~2002-08-04 0:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-04 0:27 Han-Wen [this message]
2002-08-05 18:18 ` new GC code merged Marius Vollmer
2002-08-17 5:30 ` Lynn Winebarger
2002-08-18 0:36 ` Han-Wen Nienhuys
2002-08-18 1:31 ` Lynn Winebarger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15692.29931.82055.847632@blauw.xs4all.nl \
--to=hanwen@cs.uu.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).