|
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
|
|
|
5 New KKCC-GC mark algorithm:
|
|
|
6 configure flag : --use-kkcc
|
|
|
7
|
|
|
8 For better understanding, first a few words about the mark algorithm
|
|
|
9 up to now:
|
|
|
10 Every Lisp_Object has its own mark method, which calls mark_object
|
|
|
11 with the stuff to be marked.
|
|
|
12 Also, many Lisp_Objects have pdump descriptions, which are used by
|
|
|
13 the portable dumper. The dumper gets all the information it needs
|
|
|
14 about the Lisp_Object from the descriptions.
|
|
|
15
|
|
|
16 Also the garbage collector can use the information in the pdump
|
|
|
17 descriptions, so we can get rid of the mark methods.
|
|
|
18 That is what we have been doing.
|
|
|
19
|
|
|
20
|
|
|
21 DUMPABLE FLAG
|
|
|
22 -------------
|
|
|
23 First we added a dumpable flag to lrecord_implementation. It shows,
|
|
|
24 if the object is dumpable and should be processed by the dumper.
|
|
|
25 The dumpable flag is the third argument of a lrecord_implementation
|
|
|
26 definition (DEFINE_LRECORD_IMPLEMENTATION).
|
|
|
27 If it is set to 1, the dumper processes the descriptions and dumps
|
|
|
28 the Object, if it is set to 0, the dumper does not care about it.
|
|
|
29
|
|
|
30
|
|
|
31 XD_UNION
|
|
|
32 --------
|
|
|
33 We implemented XD_UNION support in (mark_with_description), so
|
|
|
34 we can describe exspecially console/device specific data with XD_UNION.
|
|
|
35 To describe with XD_UNION, we added a field to these objects, which
|
|
|
36 holds the variant type of the object. This field is initialized in
|
|
|
37 the appendant constructor. The variant is an integer, it has also to
|
|
|
38 be described in an description, if XD_UNION is used.
|
|
|
39
|
|
|
40 Here is a pattern of a XD_UNION usage:
|
|
|
41
|
|
|
42 First, the existing variants are listed.
|
|
|
43 enum example_variant
|
|
|
44 {
|
|
|
45 first_choice,
|
|
|
46 second_choice
|
|
|
47 };
|
|
|
48
|
|
|
49 Then a field which holds the variant is added to the Lisp_Object.
|
|
|
50 This field determines, where pointer points to.
|
|
|
51 struct Lisp_...
|
|
|
52 {
|
|
|
53 enum example_variant which_variant;
|
|
|
54 ...
|
|
|
55 void *pointer;
|
|
|
56 }
|
|
|
57 The variant field must be initialized in the constructor(s).
|
|
|
58
|
|
|
59 In the description, the first entry should be the which_variant field,
|
|
|
60 on which XD_UNION refers.
|
|
|
61 static const struct lrecord_description ..._description [] = {
|
|
|
62 { XD_INT, offsetof (struct Lisp_..., which_variant) },
|
|
|
63 ...
|
|
|
64 { XD_UNION, offsetof (struct Lisp_..., which_variant),
|
|
|
65 XD_INDIRECT (0, 0), variant_description },
|
|
|
66 ...
|
|
|
67 };
|
|
|
68
|
|
|
69 The variant_description looks like this:
|
|
|
70 static const struct struct_description variant_description []= {
|
|
|
71 { first_choice, first_choice_description},
|
|
|
72 { second_choice, second_choice__description},
|
|
|
73 { XD_END }
|
|
|
74 };
|
|
|
75
|
|
|
76 first- and second_choice_description are common lrecord_descriptions:
|
|
|
77 static const struct lrecord_description first_choice_description [] = {
|
|
|
78 ...
|
|
|
79 { XD_END }
|
|
|
80 }
|
|
|
81
|
|
|
82
|
|
|
83
|
|
|
84 TODO
|
|
|
85 ----
|
|
|
86
|
|
|
87 The following objects have currently no description:
|
|
|
88 * alloc.c: lcrecord_list
|
|
|
89 mark_object is never called, marking is done per mane.
|
|
|
90
|
|
|
91 * buffer.c: mark_buffer
|
|
|
92 mark_conses_in_list implements weakness???
|
|
|
93
|
|
|
94 * extents.c: extent_info
|
|
|
95 loop to mark elements in list.
|
|
|
96
|
|
|
97 * frame.c: frame
|
|
|
98 calls mark_gutters, that calls mark_redisplay_structs
|
|
|
99
|
|
|
100 * glyphs.c: image_instance
|
|
|
101 XD_UNION or convert the union members to Lisp_Objects (see Lisp_Event)
|
|
|
102
|
|
|
103 * gui-x.c: popup_data
|
|
|
104 calls lw_map_widget_values
|
|
|
105
|
|
|
106 * window.c: window
|
|
|
107 calls mark_face_cachels and mark_glyph_cachels
|
|
|
108
|
|
|
109 window_configuration
|
|
|
110 loop to mark saved_windows
|
|
|
111
|
|
|
112 window_mirror
|
|
|
113 calls mark_redisplay_structs
|
|
|
114
|
|
|
115 * lstream.c: lstream
|
|
|
116
|
|
|
117
|
|
|
118 After all Lisp_Objects have pdump descriptions,
|
|
|
119 (mark_with_description) can get rid of the mark_object calls.
|
|
|
120
|
|
|
121
|
|
|
122 There are a few Lisp_Objects, where there occured differences and
|
|
|
123 inexactness between the mark-method and the pdump description.
|
|
|
124 All these Lisp_Objects get dumped, so their descriptions have been
|
|
|
125 written, before we started our work:
|
|
|
126
|
|
|
127 * alloc.c: cons
|
|
|
128 description: car and cdr
|
|
|
129 mark: cdr is marked, only if its != Qnil
|
|
|
130
|
|
|
131 * alloc.c: string
|
|
|
132 description:
|
|
|
133 mark:
|
|
|
134
|
|
|
135 * elhash.c: hash_table
|
|
|
136 description: the weakness receives no consideration
|
|
|
137 mark: weakness == HASH_TABLE_NON_WEAK
|
|
|
138
|
|
|
139 * eval.c: subr
|
|
|
140 description: XD_DOC_STRING doc
|
|
|
141 mark: empty, nothing is marked
|
|
|
142
|
|
|
143 * file-coding.c: coding_system
|
|
|
144 description:
|
|
|
145 mark:
|
|
|
146
|
|
|
147 * frame.c: bit_vektor
|
|
|
148 description: XD_LISP_OBJECT next
|
|
|
149 mark: empty, nothing is marked
|
|
|
150
|
|
|
151 * marker.c: marker
|
|
|
152 description: prev & next (marker's chain)
|
|
|
153 mark: do not mark through marker's chain!
|
|
|
154
|
|
|
155 * specifier.c: specifier
|
|
|
156 description: XD_STRUCT_PTR caching
|
|
|
157 mark: caching is not marked
|
|
|
158
|
|
|
159 * symbols.c: symbol-value-lisp-magic
|
|
|
160 description: only handler[] is described
|
|
|
161 mark: even harg[] and shadowed are marked
|
|
|
162
|
|
|
163 * data.c: ephemeron
|
|
|
164 description: everything is marked, there is no weakness!
|
