Mercurial > hg > xemacs-beta
annotate src/README.kkcc @ 5533:11da5b828d10
shell-command and shell-command-on-region API compliant with FSF 23.3.1
| author | Mats Lidell <mats.lidell@cag.se> |
|---|---|
| date | Sun, 31 Jul 2011 01:29:09 +0200 |
| parents | 3889ef128488 |
| children |
| rev | line source |
|---|---|
| 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 |
|
5384
3889ef128488
Fix misspelled words, and some grammar, across the entire source tree.
Jerry James <james@xemacs.org>
parents:
1598
diff
changeset
|
56 There are a few Lisp_Objects, where there occurred differences and |
| 1204 | 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. |