Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!swrinde!howland.reston.ans.net!math.ohio-state.edu!uwm.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!in1.uu.net!allegra!alice!gad.research.att.com!user
From: pereira@research.att.com (Fernando Pereira)
Subject: Re: quintus prolog garbage collection problem
X-Nntp-Posting-Host: gad.research.att.com
Message-ID: <pereira-2404961855260001@gad.research.att.com>
Sender: usenet@research.att.com (netnews <9149-80593> 0112740)
Organization: AT&T Bell Laboratories
References: <317D6751.6D29@regenisys.com>
Date: Wed, 24 Apr 1996 22:55:26 GMT
Lines: 30

In article <317D6751.6D29@regenisys.com>, Jerry Ball
<jerryb@regenisys.com> wrote:

> I ran into a problem in the garbage collection routine
> of quintus prolog.  Under some circumstances, garbage collection
> starts thrashing.  For example, this can occur when recursively
> operating on large lists.  Unfortunately, there does not appear to be
> anybody at Quintus who can even look into fixing this problem!
> [...]
> The recursive way it was:
> 
> p([],[]).
> p([H|T],[D|R]) :-
>    q(H,D),  % this creates lots of "garbage" which would be OK 
>             % if garbage collection worked properly
>    p(T,R).
Can you elaborate? I've written (not recently) a lot of code with that
general structure that worked fine in QP. Their GC has various parameters
that can be adjusted to handle better tight memory situations or avoid
overcollection when there is a lot of memory churn. (The manual has
details on this). Have you tried to adjust those parameters? Also, are you
sure that q/2 and p/2 are really making heap frames available for
collection? Any choice points left in the execution of q(H,D) or p(T,R)
will lock down heap frames and make them uncollectable.

-- 
Fernando Pereira
2B-441, AT&T Bell Laboratories
600 Mountain Ave, Murray Hill, NJ 07974-0636
pereira@research.att.com
