[antlr-interest] nodes, hidden tokens, garbage collection

John Allen Green greenj at ix.netcom.com
Wed Apr 3 12:42:06 PST 2002


--On 03/04/2002 10:51 AM +0200 Ric Klaren wrote:
> Add 2 & 3: You can change the AST's to use a memory pool (add custom
> new/delete) and hack a bit on the codegenerator and support lib to
> completely loose the RefCounts. This would probably clean the code up
> quite a ways. After that build the AST as usual and at the end do a
> garbage collection over you memory pool.


Oi, I was hoping to avoid doing any surgery on Antlr. Getting rid of the
reference counting would be very nice, but I think it would be a significant
task.

How were you planning to implement the memory pool? Use a vector<AST>, or
something lower level? There's always the Boehm GCC route, as well.

Were you planning to eliminate RefToken and RefAST by replacing them with
pointers?

As a sort-of-related aside: I've changed my AST / token relationship. I've
added a few extra bits of information into the tokens, which needs to
remain available through to the AST. Rather than copy all this information
from token to AST and then delete the token, I'm keeping a reference to the
token within the AST node. I don't think this impacts my ability to migrate
to a memory pool, but it's something I have to keep in mind.

There's another option for my specific needs. There's a style of reference
counting which uses two counters - one for strong references and one for
weak references. Done right, it eliminates problems with cyclic
dependencies. I've read about it, but I haven't found an example
implementation yet. I could use this easily for my AST, but to implement it
for the hidden tokens, I would have to hack or replace one or two chunks of
the Antlr library.

Of course, going that route would still leave me with the reference
counting, which I agree is a pain.

John
 


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



More information about the antlr-interest mailing list