Re: [Texmacs-dev] Boehm-gc-texmacs gc behavior (was: Re: Boehm-gc-texmacs cache behavior)

[Joris van der Hoeven]

> > For (3), I can't tell. Is texmacs allocating large objects?
>
> Depends on what you call large, but I'd rather say no. Well there can be
> a few large objects (resources, structures relating to the top DOCUMENT
> node of large documents). But programmers are notoriously bad at
> guessing the allocation patterns of their programs.
>
> Empirical data would be useful here. You can gather that data by
> modifying the custom allocator on a non GC-enabled texmacs.

The (show-meminfo) function provides some information.
For instance, after generating the users manual, I obtain:

---------------- memory statistics ----------------
User          : 56548924 bytes
Allocator     : 58150168 bytes
Small mallocs : 88.1441%

Here "small mallocs" are mallocs of <=256 bytes (they are treated
in an especially efficient way by TeXmacs).

By the way, it seems that there is a bug in the memory allocation
system for recent TeXmacs releases (I did not test for more than a year).
The allocated amount of memory strictly increases if I kill the buffer
and regenerate the documentation several times (or update the buffer
several times). If someone could track that bug down (one may start
by identifying in which version this bug occurs for the first time)...

> > I hope it lights a candle in this GC dark. :) But as you have done the
> > port, only you David can tell what is going wrong.
>
> There is probably still ample room for improvement in the GC support,
> but, by it's very nature, GC is expensive in memory compared to pointer
> counting.

No, this is not true. So far you have been focussing on Boehme's GC,
which is a "poor mans" GC in the sense that it provides a reliable GC
without much work for the programmer.

GC's which are traditionnaly being used by programming languages
(like Guile) have special routines for marking used objects or
copying/compactifying used objects. In that case, a one word field
(like the current ref_count field) may be used for marking purposes
and not much more overhead is needed (except possibly for compactifying
allocators, but some tricks might apply there).

One strategy would therefore be to write marking routines for
all TeXmacs data types. That it cumbersome, but would allow for
essentially better conservative garbage collection.