Mercurial > hg > xemacs-beta

comparison src/README.kkcc @ 992:964f33d24564

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
[xemacs-hg @ 2002-09-03 10:51:55 by michaels] Belated addition to the KKCC commit---I had forgotten this file.
author michaels
date Tue, 03 Sep 2002 10:51:55 +0000
parents
children e22b0213b713
comparison
equal deleted inserted replaced
991:a28c97bd4634 992:964f33d24564
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!