|
992
|
1 2002-07-17 Marcus Crestani <crestani@informatik.uni-tuebingen.de>
|
|
|
2 Markus Kaltenbach <makalten@informatik.uni-tuebingen.de>
|
|
|
3 Mike Sperber <mike@xemacs.org>
|
|
|
4
|
|
1598
|
5 updated 2003-07-29
|
|
|
6
|
|
992
|
7 New KKCC-GC mark algorithm:
|
|
|
8 configure flag : --use-kkcc
|
|
|
9
|
|
|
10 For better understanding, first a few words about the mark algorithm
|
|
|
11 up to now:
|
|
|
12 Every Lisp_Object has its own mark method, which calls mark_object
|
|
|
13 with the stuff to be marked.
|
|
1598
|
14 Also, many Lisp_Objects have pdump descriptions memory_descriptions,
|
|
|
15 which are used by the portable dumper. The dumper gets all the
|
|
|
16 information it needs about the Lisp_Object from the descriptions.
|
|
992
|
17
|
|
|
18 Also the garbage collector can use the information in the pdump
|
|
|
19 descriptions, so we can get rid of the mark methods.
|
|
|
20 That is what we have been doing.
|
|
|
21
|
|
|
22
|
|
|
23 DUMPABLE FLAG
|
|
|
24 -------------
|
|
|
25 First we added a dumpable flag to lrecord_implementation. It shows,
|
|
|
26 if the object is dumpable and should be processed by the dumper.
|
|
|
27 The dumpable flag is the third argument of a lrecord_implementation
|
|
|
28 definition (DEFINE_LRECORD_IMPLEMENTATION).
|
|
|
29 If it is set to 1, the dumper processes the descriptions and dumps
|
|
|
30 the Object, if it is set to 0, the dumper does not care about it.
|
|
|
31
|
|
|
32
|
|
1598
|
33 KKCC MARKING
|
|
|
34 ------------
|
|
|
35 All Lisp_Objects have memory_descriptions now, so we could get
|
|
|
36 rid of the mark_object calls.
|
|
|
37 The KKCC algorithm manages its own stack. Instead of calling
|
|
|
38 mark_object, all the alive Lisp_Objects are pushed on the
|
|
|
39 kkcc_gc_stack. Then these elements on the stack are processed
|
|
|
40 according to their descriptions.
|
|
|
41
|
|
|
42
|
|
992
|
43 TODO
|
|
|
44 ----
|
|
1598
|
45 - For weakness use weak datatypes instead of XD_FLAG_NO_KKCC.
|
|
|
46 XD_FLAG_NO_KKCC occurs in:
|
|
|
47 * elhash.c: htentry
|
|
|
48 * extents.c: lispobject_gap_array, extent_list, extent_info
|
|
|
49 * marker.c: marker
|
|
|
50 Not everything has to be rewritten. See Ben's comment in lrecord.h.
|
|
|
51 - Clean up special case marking (weak_hash_tables, weak_lists,
|
|
|
52 ephemerons).
|
|
|
53 - Stack optimization (have one stack during runtime instead of
|
|
|
54 malloc/free it for every garbage collect)
|
|
992
|
55
|
|
1204
|
56 There are a few Lisp_Objects, where there occured differences and
|
|
|
57 inexactness between the mark-method and the pdump description. All
|
|
|
58 these Lisp_Objects get dumped (except image instances), so their
|
|
|
59 descriptions have been written, before we started our work:
|
|
992
|
60 * alloc.c: string
|
|
1598
|
61 description: size_, data_, and plist is described
|
|
|
62 mark: only plist is marked, but flush_cached_extent_info is called.
|
|
|
63 flush_cached_extent_info ->
|
|
|
64 free_soe ->
|
|
|
65 free_extent_list ->
|
|
|
66 free_gap_array ->
|
|
|
67 gap_array_delete_all_markers ->
|
|
|
68 Add gap_array to the gap_array_marker_freelist
|
|
992
|
69
|
|
1204
|
70 * glyphs.c: image_instance
|
|
1598
|
71 description: device is not set to nil
|
|
1204
|
72 mark: mark method sets device to nil if dead
|
|
1598
|
73 See comment above the description.
|
