RE: [ng-spice] Problems with GC malloc


To "'ng-spice@ieee.ing.uniroma1.it'" <ng-spice@ieee.ing.uniroma1.it>
From "Gillespie, Alan" <Alan.Gillespie@analog.com>
Date Tue, 5 Jun 2001 10:31:16 +0100
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
Mailing-List contact ng-spice-help@ieee.ing.uniroma1.it; run by ezmlm
Reply-To ng-spice@ieee.ing.uniroma1.it


I'm not sure if it's been fixed in ngspice, but Berkeley
Spice does an awful lot of "reallocing". I found that with
Borland C in Win32, this lead to a massive heap. This is
because Spice keeps reallocing blocks to be only one "unit"
bigger than it was before. If something else has been malloced
since the block was originally malloced, then it won't fit,
so a new block has to be allocated.

Borland C uses the Win32 heaps directly (they're an
operating system function in Win32), but the standard
heaps don't consolidate free blocks. So every realloc
takes a bit more from the virtual memory space, and needs
another block on the heap.

Maybe the GC heap has a similar problem. Maybe there's a
specific heap function to consolidate the unused blocks
(I've a feeling Windows NT has that, but not Win9x). Or
maybe you could do something like I did in alloc.c in
the misc directory. The idea is that when I realloc something,
I stick some extra space at the end :-

char *
trealloc(str, num)
    char *str;
    int num;
{
    char *s;

    if (!num) {
        if (str)
                free(str);
        return NULL;
    }

    if (!str)
#if defined(AlansFixes) && defined(__BORLANDC__)
        if (num<64) {
           s = tmalloc(64);
           s = realloc(s, num);
        } else s = tmalloc(num);
#else
        s = tmalloc(num);
#endif
    else
#if defined(AlansFixes) && defined(__BORLANDC__)
       {
        s = _expand(str, (unsigned) num);
        if (s==NULL) {
/*        fprintf(stderr, "Expand failed. Allocating block %d\n", 2*num); */
          s = tmalloc(2*num);
          s = realloc(s, (unsigned) num);
          if (s!=NULL) {
            memcpy(s, str, _msize(str));
            if (str) free(str);
          }
        } else {
/*         fprintf(stderr, "Expand successful.\n"); */
        }
       }
#else
        s = realloc(str, (unsigned) num);
#endif

    if (!s) {
        fprintf(stderr, 
                "realloc: Internal Error: can't allocate %d bytes.\n", num);
        exit(EXIT_BAD);
    }
    return(s);
}


Of course, it may have nothing to do with this :-)


> -----Original Message-----
> From: Robert Penny [mailto:rob@network.ucsd.edu]
> Sent: 04 June 2001 21:50
> To: ng-spice mailing list
> Subject: [ng-spice] Problems with GC malloc
> 
> 
> Hi,
> 
> I'm using ng-spice-rework14-pre2 to perform a transient analysis on 
> a design with 3076 MOSFETs and 4673 capacitors.  Analysis on a smaller
> design with 880 MOSFETs and 1756 capacitors completes successfully in
> about 6 minutes.  On the larger design the simulation dies after 20
> minutes with the error:
> 
>      Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
>      Aborted
> 
> The error is actually coming from gc malloc not from ngspice but I'm
> wondering if it is a symptom of something that ngspice is doing.
> 
> I've tried compiling gc malloc with -DLARGE_CONFIG but spice is still
> running out of memory... or rather gc malloc is having 
> problems.  At its
> maximum spice is still only taking 7.5% of physical memory ( 
> 7.5% of 750
> MB ) when it dies.
> 
> I seem to remember there being some good reason I was working with the
> GC_MALLOC version of ngspice rather than the non- GC_MALLOC version,
> though I'm going to try recompiling with this turned off to 
> see if I can
> get my analysis to complete.
> 
> I'm running on a linux system with glibc 2.1.2.
> 
> Does anyone have any insight into the problem, or at least 
> experience with
> analysis of designs of comparable size in ngspice?
> 
> Thanks in advance,
> 
> -Rob Penny (rob@ucsd.edu)
> 

Partial thread listing: