Re: Parse tree creation question

Chris Dodd <chrisd@reservoir.com>
23 Mar 2000 22:39:48 -0500

          From comp.compilers

Related articles
Parse tree creation question lojedaortiz@interlink.com.ar (Nicolas) (2000-03-11)
Re: Parse tree creation question qjackson@wave.home.com (Quinn Tyler Jackson) (2000-03-21)
Re: Parse tree creation question glouis@univ-lr.fr (Georges LOUIS) (2000-03-23)
Re: Parse tree creation question chrisd@reservoir.com (Chris Dodd) (2000-03-23)
| List of all articles for this month |

From: Chris Dodd <chrisd@reservoir.com>
Newsgroups: comp.compilers
Date: 23 Mar 2000 22:39:48 -0500
Organization: Bay Area Internet Solutions
References: 00-03-077 00-03-081
Keywords: parse, question



> I am creating my abstract syntax tree with bison. I have some rules like
> this:
>
> a: b c { $$ = gProgram = new a( $1, $2 ); } ;
> b: d { $$ = new b( $1 ); } ;
> c: e { $$ = new c( $1 ); } ;
>
> Now, if the parsing phase doesn't fail, when a gets reduced, gProgram
> is a pointer to the entire parse tree, so I can't deallocate it when I
> am done working with it. But, if the parsing phase fails for any
> reason, I can't deallocate the nodes constructed up to the momento of
> failure, since I have no pointer to them.


Basically, the answer comes down to garbage collection. To solve the
problem, you need some kind of garbage collector as you can't predict
easily when you need to deallocate objects.


So, you have two choices
a) use an existing garbage collector, either built into your
      language/compiler, or a bolt-on such as the Boehm-Weiser
      conservative collector (works well with C/C++ and yacc in
      my experience)
b) roll your own garbage collector. There are lots of ways of
      doing this. In C++ you can use `smart-pointers' to implement
      a reference counting scheme. Alternately, you can use a `pool'
      scheme where you keep track of all the objects allocated and
      periodically sweep the pool, freeing unneeded objects (mark-sweep
      collection) or copy the relevant objects to a new pool and free
      the entire old pool (copy collection).


(a) is certainly the easier choice, but (b) does have some advantages.
You can tune the garbage collector to the application (in this case,
a compiler), and trigger garbage collection at opportune points when
the total live data is small, which can significantly reduce the overhead.
Depending on your compiler, however, this overhead may be a tiny
proportion of the overall time.


Chris Dodd
chrisd@reservoir.com


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.