Path: utzoo!utgpu!watserv1!watmath!att!att!ima!esegue!compilers-sender
From: pardo@cs.washington.edu (David Keppel)
Newsgroups: comp.compilers
Subject: Re: Question About YACC's Memory Management
Keywords: yacc
Message-ID: <13487@june.cs.washington.edu>
Date: 23 Oct 90 17:32:46 GMT
References: <1990Oct18.213224.21195@csrd.uiuc.edu> <14252@goofy.megatest.UUCP>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: pardo@cs.washington.edu (David Keppel)
Organization: University of Washington, Computer Science, Seattle
Lines: 48
Approved: compilers@esegue.segue.boston.ma.us

>andrea@mprgate.mpr.ca (Jennitta Andrea) writes:
>> [Call the parser repeatedly from a driver.]
>> [|malloc| each token in lex; yacc doesn't |free|.]

djones@megatest.uucp (Dave Jones) writes:
>[Borrow an string table package; free at one go.
> But why copy at all?  Read input into a buffer & pools of tokens.]

Ah, yes -- The way GNU CC does it (at least recently) is to use an
``obstack'' package.  The ``obstack'' package is sort of a cross
between |malloc| and |alloca|.  Things are allocated in stack order on
an ``obstack'' and are freed ``when you know it is safe.''  In
addition, it is possible to tentatively allocate a thing on the stack,
and then grow it or shrink it until its size is known, then ``freeze''
it and go on to the next allocation.

Furthermore, if you have things that need to live until the end of the
parse, but aren't needed as long as the parse tree, you can allocate
stuff on a shorter-lived store.

    obstack_init (&short_store);
    obstack_init (&long_store);
    short_watermark = oballoc (&short_store, 0);
    long_watermark = oballoc (&long_store, 0);

    while (1) {
	parse();
	/* Free temps used by the parser but not used in parse tree.  */
	obfree (&short_store, short_watermark);

	use (parser_output);
	/* Free everything allocaetd by the parser. */
	obfree (&long_store, long_watermark);

	... other stuff not needing parser output ...
    }

Dave Jones' sollution is probably fastest, while using a generic
allocator allows for more efficient use of memory when there are
variable-sized objects.

	;-D oN  ( HACC memory management )  Pardo
-- 
		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.