Mercurial > hg > xemacs-beta
annotate modules/README @ 5160:ab9ee10a53e4
fix various problems with allocation statistics, track overhead properly
-------------------- ChangeLog entries follow: --------------------
lisp/ChangeLog addition:
2010-03-20 Ben Wing <ben@xemacs.org>
* diagnose.el (show-memory-usage):
* diagnose.el (show-object-memory-usage-stats):
Further changes to correspond with changes in the C code;
add an additional column showing the overhead used with each type,
and add it into the grand total memory usage.
src/ChangeLog addition:
2010-03-20 Ben Wing <ben@xemacs.org>
* alloc.c:
* alloc.c (init_lrecord_stats):
* alloc.c (free_normal_lisp_object):
* alloc.c (struct):
* alloc.c (clear_lrecord_stats):
* alloc.c (tick_lrecord_stats):
* alloc.c (COUNT_FROB_BLOCK_USAGE):
* alloc.c (COPY_INTO_LRECORD_STATS):
* alloc.c (sweep_strings):
* alloc.c (UNMARK_string):
* alloc.c (gc_sweep_1):
* alloc.c (finish_object_memory_usage_stats):
* alloc.c (object_memory_usage_stats):
* alloc.c (object_dead_p):
* alloc.c (fixed_type_block_overhead):
* alloc.c (lisp_object_storage_size):
* emacs.c (main_1):
* lisp.h:
* lrecord.h:
Export lisp_object_storage_size() and malloced_storage_size() even
when not MEMORY_USAGE_STATS, to get the non-MEMORY_USAGE_STATS
build to compile.
Don't export fixed_type_block_overhead() any more.
Some code cleanup, rearrangement, add some section headers.
Clean up various bugs especially involving computation of overhead
and double-counting certain usage in total_gc_usage. Add
statistics computing the overhead used by all types. Don't add a
special entry for string headers in the object-memory-usage-stats
because it's already present as just "string". But do count the
overhead used by long strings. Don't try to call the
memory_usage() methods when NEW_GC because there's nowhere obvious
in the sweep stage to make the calls.
* marker.c (compute_buffer_marker_usage):
Just use lisp_object_storage_size() rather than trying to
reimplement it.
| author | Ben Wing <ben@xemacs.org> |
|---|---|
| date | Sat, 20 Mar 2010 20:20:30 -0500 |
| parents | 25e260cb7994 |
| children | da1365dd3f07 |
| rev | line source |
|---|---|
| 996 | 1 This directory contains a number of XEmacs dynamic modules. These |
| 2 modules can be loaded directly with the command 'M-x load-module'. | |
| 3 However, the preferred method of loading a module is to issue a | |
| 4 "(require 'module-name)" command to the Lisp interpreter. This will | |
| 5 store information so that a later "(unload-feature 'module-name)" can | |
| 6 succeed. | |
| 388 | 7 |
| 996 | 8 To compile one of these modules, simply enter the desired directory, |
| 9 type 'configure', and then 'make'. If you are building the module for | |
| 10 an installed XEmacs, then 'make install' will place the module in the | |
| 11 appropriate directory for XEmacs to find it later (assuming you have | |
| 12 permission to write to that directory). A subsequent 'load-module' or | |
| 13 'require' will then load the module, as described above. | |
| 388 | 14 |
| 996 | 15 Each of these demonstrates different features and limitations of the |
| 16 XEmacs module loading technology. For a complete discussion on XEmacs | |
| 17 dynamic modules, please consult the XEmacs Module Writers Guide, which | |
| 18 can be found in the ../info directory. | |
| 388 | 19 |
| 996 | 20 For those wanting to get started with module writing, please see the |
| 21 'sample' directory. It contains two subdirectories: internal and | |
| 22 external. The 'internal' subdirectory contains the framework needed to | |
| 23 migrate some core piece of XEmacs functionality into code that can | |
| 24 either be compiled into the core or built as a separate module. The | |
| 25 'external' subdirectory contains the somewhat simpler framework needed | |
| 26 to build a module separately from XEmacs. These should be considered | |
| 27 starting places for module writing. |