-This is Info file ../info/internals.info, produced by Makeinfo version
-1.68 from the input file internals/internals.texi.
+This is ../info/internals.info, produced by makeinfo version 4.0b from
+internals/internals.texi.
INFO-DIR-SECTION XEmacs Editor
START-INFO-DIR-ENTRY
-* Internals: (internals). XEmacs Internals Manual.
+* Internals: (internals). XEmacs Internals Manual.
END-INFO-DIR-ENTRY
Copyright (C) 1992 - 1996 Ben Wing. Copyright (C) 1996, 1997 Sun
Similar to other subsystems in XEmacs, lstreams are separated into
generic functions and a set of methods for the different types of
lstreams. `lstream.c' provides implementations of many different types
-of streams; others are provided, e.g., in `mule-coding.c'.
+of streams; others are provided, e.g., in `file-coding.c'.
fileio.c
with them, in case the block of memory contains other Lisp objects that
need to be marked for garbage-collection purposes. (If you need other
object methods, such as a finalize method, you should just go ahead and
-create a new Lisp object type - it's not hard.)
+create a new Lisp object type--it's not hard.)
abbrev.c
This module provides some terminal-control code necessary on
versions of AIX prior to 4.1.
- msdos.c
- msdos.h
-
- These modules are used for MS-DOS support, which does not work in
-XEmacs.
-
\1f
File: internals.info, Node: Modules for Interfacing with X Windows, Next: Modules for Internationalization, Prev: Modules for Interfacing with the Operating System, Up: A Summary of the Various XEmacs Modules
(graphics contexts) under the X Window System. This code is junky and
needs to be rewritten.
- xselect.c
+ select-msw.c
+ select-x.c
+ select.c
+ select.h
This module provides an interface to the X Window System's concept of
"selections", the standard way for X applications to communicate with
mule-ccl.c
mule-charset.c
mule-charset.h
- mule-coding.c
- mule-coding.h
+ file-coding.c
+ file-coding.h
mule-mcpath.c
mule-mcpath.h
mule-wnnfns.c
not just Asian languages (although they are generally the most
complicated to support). This code is still in beta.
- `mule-charset.*' and `mule-coding.*' provide the heart of the XEmacs
+ `mule-charset.*' and `file-coding.*' provide the heart of the XEmacs
MULE support. `mule-charset.*' implements the "charset" Lisp object
type, which encapsulates a character set (an ordered one- or
two-dimensional set of characters, such as US ASCII or JISX0208 Japanese
Kanji).
- `mule-coding.*' implements the "coding-system" Lisp object type,
+ `file-coding.*' implements the "coding-system" Lisp object type,
which encapsulates a method of converting between different encodings.
An encoding is a representation of a stream of characters, possibly
from multiple character sets, using a stream of bytes or words, and
Asian-language support, and is not currently used.
\1f
-File: internals.info, Node: Allocation of Objects in XEmacs Lisp, Next: Events and the Event Loop, Prev: A Summary of the Various XEmacs Modules, Up: Top
+File: internals.info, Node: Allocation of Objects in XEmacs Lisp, Next: Dumping, Prev: A Summary of the Various XEmacs Modules, Up: Top
Allocation of Objects in XEmacs Lisp
************************************
* Allocation from Frob Blocks::
* lrecords::
* Low-level allocation::
-* Pure Space::
* Cons::
* Vector::
* Bit Vector::
* Compiled Function::
\1f
-File: internals.info, Node: Introduction to Allocation, Next: Garbage Collection, Up: Allocation of Objects in XEmacs Lisp
+File: internals.info, Node: Introduction to Allocation, Next: Garbage Collection, Prev: Allocation of Objects in XEmacs Lisp, Up: Allocation of Objects in XEmacs Lisp
Introduction to Allocation
==========================
one C primitive for creating it.
Recall from section (VII) that a Lisp object, as stored in a 32-bit
-or 64-bit word, has a mark bit, a few tag bits, and a "value" that
-occupies the remainder of the bits. We can separate the different Lisp
-object types into four broad categories:
+or 64-bit word, has a few tag bits, and a "value" that occupies the
+remainder of the bits. We can separate the different Lisp object types
+into three broad categories:
* (a) Those for whom the value directly represents the contents of
the Lisp object. Only two types are in this category: integers and
necessary for such objects. Lisp objects of these types do not
need to be `GCPRO'ed.
- In the remaining three categories, the value is a pointer to a
-structure.
-
- * (b) Those for whom the tag directly specifies the type. Recall
- that there are only three tag bits; this means that at most five
- types can be specified this way. The most commonly-used types are
- stored in this format; this includes conses, strings, vectors, and
- sometimes symbols. With the exception of vectors, objects in this
- category are allocated in "frob blocks", i.e. large blocks of
- memory that are subdivided into individual objects. This saves a
- lot on malloc overhead, since there are typically quite a lot of
- these objects around, and the objects are small. (A cons, for
- example, occupies 8 bytes on 32-bit machines - 4 bytes for each of
- the two objects it contains.) Vectors are individually
- `malloc()'ed since they are of variable size. (It would be
- possible, and desirable, to allocate vectors of certain small
- sizes out of frob blocks, but it isn't currently done.) Strings
- are handled specially: Each string is allocated in two parts, a
- fixed size structure containing a length and a data pointer, and
- the actual data of the string. The former structure is allocated
- in frob blocks as usual, and the latter data is stored in "string
- chars blocks" and is relocated during garbage collection to
- eliminate holes.
-
In the remaining two categories, the type is stored in the object
itself. The tag for all such objects is the generic "lrecord"
-(Lisp_Record) tag. The first four bytes (or eight, for 64-bit machines)
-of the object's structure are a pointer to a structure that describes
-the object's type, which includes method pointers and a pointer to a
-string naming the type. Note that it's possible to save some space by
-using a one- or two-byte tag, rather than a four- or eight-byte pointer
-to store the type, but it's not clear it's worth making the change.
-
- * (c) Those lrecords that are allocated in frob blocks (see above).
+(Lisp_Type_Record) tag. The first bytes of the object's structure are
+an integer (actually a char) characterising the object's type and some
+flags, in particular the mark bit used for garbage collection. A
+structure describing the type is accessible thru the
+lrecord_implementation_table indexed with said integer. This structure
+includes the method pointers and a pointer to a string naming the type.
+
+ * (b) Those lrecords that are allocated in frob blocks (see above).
This includes the objects that are most common and relatively
- small, and includes floats, compiled functions, symbols (when not
- in category (b)), extents, events, and markers. With the cleanup
- of frob blocks done in 19.12, it's not terribly hard to add more
- objects to this category, but it's a bit trickier than adding an
- object type to type (d) (esp. if the object needs a finalization
- method), and is not likely to save much space unless the object is
- small and there are many of them. (In fact, if there are very few
- of them, it might actually waste space.)
-
- * (d) Those lrecords that are individually `malloc()'ed. These are
+ small, and includes conses, strings, subrs, floats, compiled
+ functions, symbols, extents, events, and markers. With the
+ cleanup of frob blocks done in 19.12, it's not terribly hard to
+ add more objects to this category, but it's a bit trickier than
+ adding an object type to type (c) (esp. if the object needs a
+ finalization method), and is not likely to save much space unless
+ the object is small and there are many of them. (In fact, if there
+ are very few of them, it might actually waste space.)
+
+ * (c) Those lrecords that are individually `malloc()'ed. These are
called "lcrecords". All other types are in this category. Adding
a new type to this category is comparatively easy, and all types
added since 19.8 (when the current allocation scheme was devised,
have been in this category.
Note that bit vectors are a bit of a special case. They are simple
-lrecords as in category (c), but are individually `malloc()'ed like
+lrecords as in category (b), but are individually `malloc()'ed like
vectors. You can basically view them as exactly like vectors except
that their type is stored in lrecord fashion rather than in
directly-tagged fashion.
- Note that FSF Emacs redesigned their object system in 19.29 to follow
-a similar scheme. However, given RMS's expressed dislike for data
-abstraction, the FSF scheme is not nearly as clean or as easy to
-extend. (FSF calls items of type (c) `Lisp_Misc' and items of type (d)
-`Lisp_Vectorlike', with separate tags for each, although
-`Lisp_Vectorlike' is also used for vectors.)
-
\1f
File: internals.info, Node: Garbage Collection, Next: GCPROing, Prev: Introduction to Allocation, Up: Allocation of Objects in XEmacs Lisp
frob blocks, all vectors (which are chained in one big list), and all
lcrecords (which are likewise chained).
- Note that, when an object is marked, the mark has to occur inside of
-the object's structure, rather than in the 32-bit `Lisp_Object' holding
-the object's pointer; i.e. you can't just set the pointer's mark bit.
-This is because there may be many pointers to the same object. This
-means that the method of marking an object can differ depending on the
-type. The different marking methods are approximately as follows:
-
- 1. For conses, the mark bit of the car is set.
-
- 2. For strings, the mark bit of the string's plist is set.
-
- 3. For symbols when not lrecords, the mark bit of the symbol's plist
- is set.
-
- 4. For vectors, the length is negated after adding 1.
-
- 5. For lrecords, the pointer to the structure describing the type is
- changed (see below).
-
- 6. Integers and characters do not need to be marked, since no
- allocation occurs for them.
-
- The details of this are in the `mark_object()' function.
-
- Note that any code that operates during garbage collection has to be
-especially careful because of the fact that some objects may be marked
-and as such may not look like they normally do. In particular:
-
- Some object pointers may have their mark bit set. This will make
- `FOOBARP()' predicates fail. Use `GC_FOOBARP()' to deal with this.
-
- * Even if you clear the mark bit, `FOOBARP()' will still fail for
- lrecords because the implementation pointer has been changed (see
- below). `GC_FOOBARP()' will correctly deal with this.
-
- * Vectors have their size field munged, so anything that looks at
- this field will fail.
-
- * Note that `XFOOBAR()' macros *will* work correctly on object
- pointers with their mark bit set, because the logical shift
- operations that remove the tag also remove the mark bit.
-
- Finally, note that garbage collection can be invoked explicitly by
-calling `garbage-collect' but is also called automatically by `eval',
-once a certain amount of memory has been allocated since the last
-garbage collection (according to `gc-cons-threshold').
+ Garbage collection can be invoked explicitly by calling
+`garbage-collect' but is also called automatically by `eval', once a
+certain amount of memory has been allocated since the last garbage
+collection (according to `gc-cons-threshold').
\1f
File: internals.info, Node: GCPROing, Next: Garbage Collection - Step by Step, Prev: Garbage Collection, Up: Allocation of Objects in XEmacs Lisp
all in-use objects must be reachable somehow or other from one of the
roots of accessibility. The roots of accessibility are:
- 1. All objects that have been `staticpro()'d. This is used for any
- global C variables that hold Lisp objects. A call to
- `staticpro()' happens implicitly as a result of any symbols
- declared with `defsymbol()' and any variables declared with
- `DEFVAR_FOO()'. You need to explicitly call `staticpro()' (in the
- `vars_of_foo()' method of a module) for other global C variables
- holding Lisp objects. (This typically includes internal lists and
- such things.)
+ 1. All objects that have been `staticpro()'d or
+ `staticpro_nodump()'ed. This is used for any global C variables
+ that hold Lisp objects. A call to `staticpro()' happens implicitly
+ as a result of any symbols declared with `defsymbol()' and any
+ variables declared with `DEFVAR_FOO()'. You need to explicitly
+ call `staticpro()' (in the `vars_of_foo()' method of a module) for
+ other global C variables holding Lisp objects. (This typically
+ includes internal lists and such things.). Use
+ `staticpro_nodump()' only in the rare cases when you do not want
+ the pointed variable to be saved at dump time but rather recompute
+ it at startup.
Note that `obarray' is one of the `staticpro()'d things.
Therefore, all functions and variables get marked through this.
1. For every `GCPRON', there have to be declarations of `struct gcpro
gcpro1, gcpro2', etc.
- 2. You *must* `UNGCPRO' anything that's `GCPRO'ed, and you *must not*
+ 2. You _must_ `UNGCPRO' anything that's `GCPRO'ed, and you _must not_
`UNGCPRO' if you haven't `GCPRO'ed. Getting either of these wrong
will lead to crashes, often in completely random places unrelated
to where the problem lies.
the next enclosing stack frame. Each `GCPRO'ed thing is an
lvalue, and the `struct gcpro' local variable contains a pointer to
this lvalue. This is why things will mess up badly if you don't
- pair up the `GCPRO's and `UNGCPRO's - you will end up with
+ pair up the `GCPRO's and `UNGCPRO's--you will end up with
`gcprolist's containing pointers to `struct gcpro's or local
`Lisp_Object' variables in no-longer-active stack frames.
with `struct gcpro ngcpro1, ngcpro2', etc.), `NNGCPRON', etc.
This avoids compiler warnings about shadowed locals.
- 7. It is *always* better to err on the side of extra `GCPRO's rather
+ 7. It is _always_ better to err on the side of extra `GCPRO's rather
than too few. The extra cycles spent on this are almost never
going to make a whit of difference in the speed of anything.
One exception from this rule is if you ever plan to change the
parameter value, and store a new object in it. In that case, you
- *must* `GCPRO' the parameter, because otherwise the new object
+ _must_ `GCPRO' the parameter, because otherwise the new object
will not be protected.
So, if you create any Lisp objects (remember, this happens in all
sorts of circumstances, e.g. with `Fcons()', etc.), you are
- responsible for `GCPRO'ing them, unless you are *absolutely sure*
+ responsible for `GCPRO'ing them, unless you are _absolutely sure_
that there's no possibility that a garbage-collection can occur
while you need to use the object. Even then, consider `GCPRO'ing.
whenever a QUIT can occur where execution can continue past this.
(Remember, this is almost anywhere.)
- 10. If you have the *least smidgeon of doubt* about whether you need
+ 10. If you have the _least smidgeon of doubt_ about whether you need
to `GCPRO', you should `GCPRO'.
11. Beware of `GCPRO'ing something that is uninitialized. If you have
* sweep_bit_vectors_1::
\1f
-File: internals.info, Node: Invocation, Next: garbage_collect_1, Up: Garbage Collection - Step by Step
+File: internals.info, Node: Invocation, Next: garbage_collect_1, Prev: Garbage Collection - Step by Step, Up: Garbage Collection - Step by Step
Invocation
----------
The first thing that anyone should know about garbage collection is:
when and how the garbage collector is invoked. One might think that this
could happen every time new memory is allocated, e.g. new objects are
-created, but this is *not* the case. Instead, we have the following
+created, but this is _not_ the case. Instead, we have the following
situation:
The entry point of any process of garbage collection is an invocation
of the function `garbage_collect_1' in file `alloc.c'. The invocation
-can occur *explicitly* by calling the function `Fgarbage_collect' (in
+can occur _explicitly_ by calling the function `Fgarbage_collect' (in
addition this function provides information about the freed memory), or
-can occur *implicitly* in four different situations:
+can occur _implicitly_ in four different situations:
1. In function `main_1' in file `emacs.c'. This function is called at
each startup of xemacs. The garbage collection is invoked after all
initial creations are completed, but only if a special internal
The upshot is that garbage collection can basically occur everywhere
`Feval', respectively `Ffuncall', is used - either directly or through
another function. Since calls to these two functions are hidden in
-various other functions, many calls to `garabge_collect_1' are not
+various other functions, many calls to `garbage_collect_1' are not
obviously foreseeable, and therefore unexpected. Instances where they
are used that are worth remembering are various elisp commands, as for
example `or', `and', `if', `cond', `while', `setq', etc., miscellaneous
`gui_item_...' functions, everything related to `eval' (`Feval_buffer',
`call0', ...) and inside `Fsignal'. The latter is used to handle
-signals, as for example the ones raised by every `QUITE'-macro
-triggered after pressing Ctrl-g.
+signals, as for example the ones raised by every `QUIT'-macro triggered
+after pressing Ctrl-g.
+
+\1f
+File: internals.info, Node: garbage_collect_1, Next: mark_object, Prev: Invocation, Up: Garbage Collection - Step by Step
+
+`garbage_collect_1'
+-------------------
+
+ We can now describe exactly what happens after the invocation takes
+place.
+ 1. There are several cases in which the garbage collector is left
+ immediately: when we are already garbage collecting
+ (`gc_in_progress'), when the garbage collection is somehow
+ forbidden (`gc_currently_forbidden'), when we are currently
+ displaying something (`in_display') or when we are preparing for
+ the armageddon of the whole system (`preparing_for_armageddon').
+
+ 2. Next the correct frame in which to put all the output occurring
+ during garbage collecting is determined. In order to be able to
+ restore the old display's state after displaying the message, some
+ data about the current cursor position has to be saved. The
+ variables `pre_gc_cursor' and `cursor_changed' take care of that.
+
+ 3. The state of `gc_currently_forbidden' must be restored after the
+ garbage collection, no matter what happens during the process. We
+ accomplish this by `record_unwind_protect'ing the suitable function
+ `restore_gc_inhibit' together with the current value of
+ `gc_currently_forbidden'.
+
+ 4. If we are concurrently running an interactive xemacs session, the
+ next step is simply to show the garbage collector's cursor/message.
+
+ 5. The following steps are the intrinsic steps of the garbage
+ collector, therefore `gc_in_progress' is set.
+
+ 6. For debugging purposes, it is possible to copy the current C stack
+ frame. However, this seems to be a currently unused feature.
+
+ 7. Before actually starting to go over all live objects, references to
+ objects that are no longer used are pruned. We only have to do
+ this for events (`clear_event_resource') and for specifiers
+ (`cleanup_specifiers').
+
+ 8. Now the mark phase begins and marks all accessible elements. In
+ order to start from all slots that serve as roots of
+ accessibility, the function `mark_object' is called for each root
+ individually to go out from there to mark all reachable objects.
+ All roots that are traversed are shown in their processed order:
+ * all constant symbols and static variables that are registered
+ via `staticpro' in the dynarr `staticpros'. *Note Adding
+ Global Lisp Variables::.
+
+ * all Lisp objects that are created in C functions and that
+ must be protected from freeing them. They are registered in
+ the global list `gcprolist'. *Note GCPROing::.
+
+ * all local variables (i.e. their name fields `symbol' and old
+ values `old_values') that are bound during the evaluation by
+ the Lisp engine. They are stored in `specbinding' structs
+ pushed on a stack called `specpdl'. *Note Dynamic Binding;
+ The specbinding Stack; Unwind-Protects::.
+
+ * all catch blocks that the Lisp engine encounters during the
+ evaluation cause the creation of structs `catchtag' inserted
+ in the list `catchlist'. Their tag (`tag') and value (`val'
+ fields are freshly created objects and therefore have to be
+ marked. *Note Catch and Throw::.
+
+ * every function application pushes new structs `backtrace' on
+ the call stack of the Lisp engine (`backtrace_list'). The
+ unique parts that have to be marked are the fields for each
+ function (`function') and all their arguments (`args').
+ *Note Evaluation::.
+
+ * all objects that are used by the redisplay engine that must
+ not be freed are marked by a special function called
+ `mark_redisplay' (in `redisplay.c').
+
+ * all objects created for profiling purposes are allocated by C
+ functions instead of using the lisp allocation mechanisms. In
+ order to receive the right ones during the sweep phase, they
+ also have to be marked manually. That is done by the function
+ `mark_profiling_info'
+
+ 9. Hash tables in XEmacs belong to a kind of special objects that
+ make use of a concept often called 'weak pointers'. To make a
+ long story short, these kind of pointers are not followed during
+ the estimation of the live objects during garbage collection. Any
+ object referenced only by weak pointers is collected anyway, and
+ the reference to it is cleared. In hash tables there are different
+ usage patterns of them, manifesting in different types of hash
+ tables, namely 'non-weak', 'weak', 'key-weak' and 'value-weak'
+ (internally also 'key-car-weak' and 'value-car-weak') hash tables,
+ each clearing entries depending on different conditions. More
+ information can be found in the documentation to the function
+ `make-hash-table'.
+
+ Because there are complicated dependency rules about when and what
+ to mark while processing weak hash tables, the standard `marker'
+ method is only active if it is marking non-weak hash tables. As
+ soon as a weak component is in the table, the hash table entries
+ are ignored while marking. Instead their marking is done each
+ separately by the function `finish_marking_weak_hash_tables'. This
+ function iterates over each hash table entry `hentries' for each
+ weak hash table in `Vall_weak_hash_tables'. Depending on the type
+ of a table, the appropriate action is performed. If a table is
+ acting as `HASH_TABLE_KEY_WEAK', and a key already marked,
+ everything reachable from the `value' component is marked. If it is
+ acting as a `HASH_TABLE_VALUE_WEAK' and the value component is
+ already marked, the marking starts beginning only from the `key'
+ component. If it is a `HASH_TABLE_KEY_CAR_WEAK' and the car of
+ the key entry is already marked, we mark both the `key' and
+ `value' components. Finally, if the table is of the type
+ `HASH_TABLE_VALUE_CAR_WEAK' and the car of the value components is
+ already marked, again both the `key' and the `value' components
+ get marked.
+
+ Again, there are lists with comparable properties called weak
+ lists. There exist different peculiarities of their types called
+ `simple', `assoc', `key-assoc' and `value-assoc'. You can find
+ further details about them in the description to the function
+ `make-weak-list'. The scheme of their marking is similar: all weak
+ lists are listed in `Qall_weak_lists', therefore we iterate over
+ them. The marking is advanced until we hit an already marked pair.
+ Then we know that during a former run all the rest has been marked
+ completely. Again, depending on the special type of the weak list,
+ our jobs differ. If it is a `WEAK_LIST_SIMPLE' and the elem is
+ marked, we mark the `cons' part. If it is a `WEAK_LIST_ASSOC' and
+ not a pair or a pair with both marked car and cdr, we mark the
+ `cons' and the `elem'. If it is a `WEAK_LIST_KEY_ASSOC' and not a
+ pair or a pair with a marked car of the elem, we mark the `cons'
+ and the `elem'. Finally, if it is a `WEAK_LIST_VALUE_ASSOC' and
+ not a pair or a pair with a marked cdr of the elem, we mark both
+ the `cons' and the `elem'.
+
+ Since, by marking objects in reach from weak hash tables and weak
+ lists, other objects could get marked, this perhaps implies
+ further marking of other weak objects, both finishing functions
+ are redone as long as yet unmarked objects get freshly marked.
+
+ 10. After completing the special marking for the weak hash tables and
+ for the weak lists, all entries that point to objects that are
+ going to be swept in the further process are useless, and
+ therefore have to be removed from the table or the list.
+
+ The function `prune_weak_hash_tables' does the job for weak hash
+ tables. Totally unmarked hash tables are removed from the list
+ `Vall_weak_hash_tables'. The other ones are treated more carefully
+ by scanning over all entries and removing one as soon as one of
+ the components `key' and `value' is unmarked.
+
+ The same idea applies to the weak lists. It is accomplished by
+ `prune_weak_lists': An unmarked list is pruned from
+ `Vall_weak_lists' immediately. A marked list is treated more
+ carefully by going over it and removing just the unmarked pairs.
+
+ 11. The function `prune_specifiers' checks all listed specifiers held
+ in `Vall_specifiers' and removes the ones from the lists that are
+ unmarked.
+
+ 12. All syntax tables are stored in a list called
+ `Vall_syntax_tables'. The function `prune_syntax_tables' walks
+ through it and unlinks the tables that are unmarked.
+
+ 13. Next, we will attack the complete sweeping - the function
+ `gc_sweep' which holds the predominance.
+
+ 14. First, all the variables with respect to garbage collection are
+ reset. `consing_since_gc' - the counter of the created cells since
+ the last garbage collection - is set back to 0, and
+ `gc_in_progress' is not `true' anymore.
+
+ 15. In case the session is interactive, the displayed cursor and
+ message are removed again.
+
+ 16. The state of `gc_inhibit' is restored to the former value by
+ unwinding the stack.
+
+ 17. A small memory reserve is always held back that can be reached by
+ `breathing_space'. If nothing more is left, we create a new reserve
+ and exit.
+
+\1f
+File: internals.info, Node: mark_object, Next: gc_sweep, Prev: garbage_collect_1, Up: Garbage Collection - Step by Step
+
+`mark_object'
+-------------
+
+ The first thing that is checked while marking an object is whether
+the object is a real Lisp object `Lisp_Type_Record' or just an integer
+or a character. Integers and characters are the only two types that are
+stored directly - without another level of indirection, and therefore
+they don't have to be marked and collected. *Note How Lisp Objects Are
+Represented in C::.
+
+ The second case is the one we have to handle. It is the one when we
+are dealing with a pointer to a Lisp object. But, there exist also three
+possibilities, that prevent us from doing anything while marking: The
+object is read only which prevents it from being garbage collected,
+i.e. marked (`C_READONLY_RECORD_HEADER'). The object in question is
+already marked, and need not be marked for the second time (checked by
+`MARKED_RECORD_HEADER_P'). If it is a special, unmarkable object
+(`UNMARKABLE_RECORD_HEADER_P', apparently, these are objects that sit
+in some const space, and can therefore not be marked, see
+`this_one_is_unmarkable' in `alloc.c').
+
+ Now, the actual marking is feasible. We do so by once using the macro
+`MARK_RECORD_HEADER' to mark the object itself (actually the special
+flag in the lrecord header), and calling its special marker "method"
+`marker' if available. The marker method marks every other object that
+is in reach from our current object. Note, that these marker methods
+should not call `mark_object' recursively, but instead should return
+the next object from where further marking has to be performed.
+
+ In case another object was returned, as mentioned before, we
+reiterate the whole `mark_object' process beginning with this next
+object.
projects / chise / xemacs-chise.git / blobdiff