unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* new GC code merged
@ 2002-08-04  0:27 Han-Wen
  2002-08-05 18:18 ` Marius Vollmer
  2002-08-17  5:30 ` Lynn Winebarger
  0 siblings, 2 replies; 5+ messages in thread
From: Han-Wen @ 2002-08-04  0:27 UTC (permalink / 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: new GC code merged
  2002-08-04  0:27 new GC code merged Han-Wen
@ 2002-08-05 18:18 ` Marius Vollmer
  2002-08-17  5:30 ` Lynn Winebarger
  1 sibling, 0 replies; 5+ messages in thread
From: Marius Vollmer @ 2002-08-05 18:18 UTC (permalink / raw)
  Cc: guile-devel

Han-Wen <hanwen@cs.uu.nl> writes:

> I merged my new GC code into HEAD.

Thanks!

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: new GC code merged
  2002-08-04  0:27 new GC code merged Han-Wen
  2002-08-05 18:18 ` Marius Vollmer
@ 2002-08-17  5:30 ` Lynn Winebarger
  2002-08-18  0:36   ` Han-Wen Nienhuys
  1 sibling, 1 reply; 5+ messages in thread
From: Lynn Winebarger @ 2002-08-17  5:30 UTC (permalink / raw)


On Saturday 03 August 2002 19:27, Han-Wen wrote:
> 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:
> 
       Excuse my ignorance.  The notes in tag.h indicate that the least significant
bit of the 2nd word of a cell is used for marking.  I was reading gc.h and it
appears the mark bits are stored separately.  On the other hand, I looked
at a copy of guile from before your changes and it might also have used separate
mark bitvectors.  
     So is that lsb of the second word of a cell actually free for some other use besides
marking?

Lynn


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: new GC code merged
  2002-08-17  5:30 ` Lynn Winebarger
@ 2002-08-18  0:36   ` Han-Wen Nienhuys
  2002-08-18  1:31     ` Lynn Winebarger
  0 siblings, 1 reply; 5+ messages in thread
From: Han-Wen Nienhuys @ 2002-08-18  0:36 UTC (permalink / raw)
  Cc: guile-devel


winebar@free-expression.org writes:

>        Excuse my ignorance.  The notes in tag.h indicate that\a the
> least significant bit of the 2nd word of a cell is used for marking.
> I was reading gc.h and it appears the mark bits are stored
> separately.  On the other hand, I looked at a copy of guile from
> before your changes and it might also have used separate mark
> bitvectors.  So is that lsb of the second word of a cell actually
> free for some other use besides marking?

This has been changed shortly after 1.4 was released. It's free for
use, but since all the tags live in the first word of a cell, I don't
readily see a use for it (but I don't know much about implementations
for LISP like languages)

-- 

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: new GC code merged
  2002-08-18  0:36   ` Han-Wen Nienhuys
@ 2002-08-18  1:31     ` Lynn Winebarger
  0 siblings, 0 replies; 5+ messages in thread
From: Lynn Winebarger @ 2002-08-18  1:31 UTC (permalink / raw)
  Cc: guile-devel

On Saturday 17 August 2002 19:36, Han-Wen Nienhuys wrote:
> owinebar@free-expression.org writes:
> 
> >        Excuse my ignorance.  The notes in tag.h indicate that the
> > least significant bit of the 2nd word of a cell is used for marking.
> > I was reading gc.h and it appears the mark bits are stored
> > separately.  On the other hand, I looked at a copy of guile from
> > before your changes and it might also have used separate mark
> > bitvectors.  So is that lsb of the second word of a cell actually
> > free for some other use besides marking?
> 
> This has been changed shortly after 1.4 was released. It's free for
> use, but since all the tags live in the first word of a cell, I don't
> readily see a use for it (but I don't know much about implementations
> for LISP like languages)
> 
      You just never know when an extra bit might come in handy.  Now that 
I look again, the comments don't say that last bit is used for gc (as they did 
a few months ago).

Lynn


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-08-18  1:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-08-04  0:27 new GC code merged Han-Wen
2002-08-05 18:18 ` Marius Vollmer
2002-08-17  5:30 ` Lynn Winebarger
2002-08-18  0:36   ` Han-Wen Nienhuys
2002-08-18  1:31     ` Lynn Winebarger

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).