[m-dev.] When is a GC not a GC?

[Fergus Henderson]

Thomas Charles CONWAY, you wrote:
> 
> Hi
> 
> I have a program which uses unsorted_solutions (via unsorted_aggregate).
> It runs for a while then dies with the following message:
> 	Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
> 	IOT trap/Abort
> Needless to say this is rather annoying!
> 
> By adding a call to io__report_stats and watching the heap usage, I've
> discovered that the GC doesn't seem to be reclaiming stuff. Actually,
> it looks like no GC's are happening at all - which is rather odd.
>
> I don't really know where to start looking for the problem,

Try the following:

	1.  Comment out or delete the `-DNO_DEBUGGING' in boehm_gc/Makefile
	2.  mmake libgc.a
	3.  link your program with the libgc.a that you just built
	4.  run your program with MERCURY_OPTIONS=-dG

(I'd have a go myself, but it looks as though the program needs X to run,
so not today.)

> I have a suspicion that maybe builtin_solutions may be leaving round a
> pointer to the (previous?) list of solutions which is fooling the GC.
> Ideas anyone?

If you are allocating lots of large bitmaps with GC_malloc()
(indirectly via your malloc() in mtcltk.m), that might explain it.

If that is the cause, a possible solution would be to delete
the definitions of malloc() etc. [or equivalently make malloc
call GC_malloc_atomic_uncollectible rather than GC_malloc]
and instead solve the problem of tcltk__create_command storing closures
in malloc()'ed memory by also storing a copy in GC_malloc()'ed
memory.    I.e. have tcltk__create_command store a global pointer to
a list of all the closures currently allocated, as well as
passing them to the tclCreateCommand() function.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.