From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Han-Wen Newsgroups: gmane.lisp.guile.devel Subject: new GC code merged Date: Sun, 4 Aug 2002 02:27:23 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <15692.29931.82055.847632@blauw.xs4all.nl> Reply-To: hanwen@cs.uu.nl NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1028420673 18486 127.0.0.1 (4 Aug 2002 00:24:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 4 Aug 2002 00:24:33 +0000 (UTC) Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17b9CB-0004o3-00 for ; Sun, 04 Aug 2002 02:24:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17b9Ch-0005IT-00; Sat, 03 Aug 2002 20:25:03 -0400 Original-Received: from smtpzilla2.xs4all.nl ([194.109.127.138]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17b9Bu-000578-00 for ; Sat, 03 Aug 2002 20:24:14 -0400 Original-Received: from blauw.xs4all.nl (blauw.xs4all.nl [213.84.26.127]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g740OCY8090001 for ; Sun, 4 Aug 2002 02:24:12 +0200 (CEST) Original-To: guile-devel@gnu.org X-Mailer: VM 7.05 under Emacs 21.2.1 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:943 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:943 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 * 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