Changes to th new GC percentage feature

Changes to th new GC percentage feature

[Stefan Monnier]

Regardnig the change below:

    2005-07-23  Richard M. Stallman  <rms@gnu.org>

	* insdel.c (syms_of_insdel): staticpro combine_after_change_buffer.

	* bytecode.c (MAYBE_GC): Test gc_cons_threshold and
	gc_relative_threshold, one by one.

	* keyboard.c (read_char): Test gc_cons_threshold.
	(syms_of_keyboard): staticpro Qecho_area_clear_hook.

	* eval.c (Feval, Ffuncall): Test gc_cons_threshold and
	gc_relative_threshold, one by one.

	* alloc.c (gc_cons_threshold): Not static.
	(gc_cons_combined_threshold): Var deleted.
	(gc_relative_threshold): New variable.
	(Fgarbage_collect, init_alloc_once): Compute gc_relative_threshold
	instead of gc_cons_combined_threshold.

	* lisp.h (gc_cons_threshold, gc_relative_threshold): Declare.
	(gc_cons_combined_threshold): Declaration deleted.

what exactly is it trying to do?  The only changes I can notice are:
- the bytecode interpreter and the eval and funcall functions now check two
  values rather than one, thus being slower.
- read_char tests gc_cons_threshold.

I'm obviously missing something.  Any hint?


        Stefan

Re: Changes to th new GC percentage feature

[Richard M. Stallman]

    what exactly is it trying to do?  The only changes I can notice are:
    - the bytecode interpreter and the eval and funcall functions now check two
      values rather than one, thus being slower.
    - read_char tests gc_cons_threshold.

There is code that temporarily changes gc_cons_threshold to prevent
GC from occurring.  It was broken and caused an infinite recursion.
I think this is the clean fix.

The slowdown is surely insignificant.

Re: Changes to th new GC percentage feature

[Stefan Monnier]

>     what exactly is it trying to do?  The only changes I can notice are:
>     - the bytecode interpreter and the eval and funcall functions now
>       check two values rather than one, thus being slower.
>     - read_char tests gc_cons_threshold.

> There is code that temporarily changes gc_cons_threshold to prevent
> GC from occurring.  It was broken and caused an infinite recursion.

I thought I had carefully updated it to change
gc_cons_combined_threshold instead.

> I think this is the clean fix.

OK.

> The slowdown is surely insignificant.

I'd expect it to be measurable since it's executed at the very least least
once per iteration of any loop.


        Stefan