Re: Forthcoming revisions to the garbage collector; crazy huge hack

nix(a)esperi.demon.co.uk writes: I think it was. Anyway, I hooked boehm 5.3 up to XEmacs 21.5 again last night, which took me all of a half hour, and it still stinks (allocation performance is _terrible_, collection is ok, leakage still seems to occur). I tried to turn on the incremental collector, but that causes crashes (in Lstream code, which I don't understand yet). I don't think this works with --pdump. Tested lightly on i686-pc-linux. gnus works ;-) I'm attaching a diff for anyone interested in playing. I'm sure there's smarter things that can be done to make it work better (I just wholesale turned off the XEmacs collector). You need to add "/where/lib/gc/is/installed/gc.a" to the linker flags for xemacs. Boehm I compiled with the following flags: -O -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DREDIRECT_MALLOC=GC_malloc Have fun! Robert Index: src/alloc.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/alloc.c,v retrieving revision 1.51 diff -u -r1.51 alloc.c --- src/alloc.c 2001/05/21 05:26:06 1.51 +++ src/alloc.c 2001/05/28 14:26:29 ＠＠ -3244,6 +3244,7 ＠＠ void garbage_collect_1 (void) { +#if 0 #if MAX_SAVE_STACK > 0 char stack_top_variable; extern char *stack_bottom; ＠＠ -3497,6 +3498,7 ＠＠ UNGCPRO; return; +#endif } /* Debugging aids. */ ＠＠ -3530,6 +3532,7 ＠＠ */ ()) { +#if 0 Lisp_Object pl = Qnil; unsigned int i; int gc_count_vector_total_size = 0; ＠＠ -3620,7 +3623,6 ＠＠ HACK_O_MATIC (cons, "cons-storage", pl); pl = gc_plist_hack ("conses-free", gc_count_num_cons_freelist, pl); pl = gc_plist_hack ("conses-used", gc_count_num_cons_in_use, pl); - /* The things we do for backwards-compatibility */ return list6 (Fcons (make_int (gc_count_num_cons_in_use), ＠＠ -3632,6 +3634,8 ＠＠ make_int (gc_count_string_total_size), make_int (gc_count_vector_total_size), pl); +#endif + return Qt; } #undef HACK_O_MATIC Index: src/emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.99 diff -u -r1.99 emacs.c --- src/emacs.c 2001/05/10 09:59:56 1.99 +++ src/emacs.c 2001/05/28 14:26:30 ＠＠ -3106,8 +3106,10 ＠＠ conversion is applied everywhere. Don't worry about memory leakage because this call only happens once. */ unexec (filename_ext, symfile_ext, (uintptr_t) my_edata, 0, 0); +#if 0 #ifdef DOUG_LEA_MALLOC free (malloc_state_ptr); +#endif #endif #endif /* not PDUMP */ } Index: src/lisp.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/lisp.h,v retrieving revision 1.51 diff -u -r1.51 lisp.h --- src/lisp.h 2001/05/18 04:39:42 1.51 +++ src/lisp.h 2001/05/28 14:26:31 ＠＠ -1938,6 +1938,7 ＠＠ NNGCPROn(). If you need to nest yet another level, create the appropriate macros. */ +#if 0 #ifdef DEBUG_GCPRO void debug_gcpro1 (char *, int, struct gcpro *, Lisp_Object *); ＠＠ -2097,6 +2098,25 ＠＠ #define NNUNGCPRO ((void) (gcprolist = nngcpro1.next)) #endif /* ! DEBUG_GCPRO */ +#endif +#define GCPRO1(v) +#define GCPRO2(v1,v2) +#define GCPRO3(v1,v2,v3) +#define GCPRO4(v1,v2,v3,v4) +#define GCPRO5(v1,v2,v3,v4,v5) +#define UNGCPRO +#define NGCPRO1(v) +#define NGCPRO2(v1,v2) +#define NGCPRO3(v1,v2,v3) +#define NGCPRO4(v1,v2,v3,v4) +#define NGCPRO5(v1,v2,v3,v4,v5) +#define NUNGCPRO +#define NNGCPRO1(v) +#define NNGCPRO2(v1,v2) +#define NNGCPRO3(v1,v2,v3) +#define NNGCPRO4(v1,v2,v3,v4) +#define NNGCPRO5(v1,v2,v3,v4,v5) +#define NNUNGCPRO /* Another try to fix SunPro C compiler warnings */ /* "end-of-loop code not reached" */ --