[antlr-interest] ASTPair handling in C# runtime for 2.7.6

Luis Leal luisl at scarab.co.za
Wed Oct 26 13:18:06 PDT 2005


Hi,

I vote for option 3 as it will have the least impact on client code and will
probably be reasonably efficient given the generational garbage collector. I
think it's probably better to spend effort on the run-time design for Antlr
v3 - which I'm very keen to help with BTW. Has work started on it? Please
let me know how I can help.

There is also a bug in the _saveIndex optimization which causes compile
errors in generated lexers. I'd be happy to contribute a patch if this
hasn't already been fixed.

Regards

Luis

-----Original Message-----
From: Micheal J [mailto:open.zone at virgin.net]
Sent: 26 October 2005 08:28 PM
To: ''antlr-interest' Interest'
Subject: [antlr-interest] ASTPair handling in C# runtime for 2.7.6


Hi,

For background info, pls see this thread:

http://www.antlr.org/pipermail/antlr-interest/2005-April/011838.html


The options currently being considered are (in order of attractiveness):

1. Rewrite ASTPair as a struct.
   Pros: no heap allocations, no GC impact/churn
   Cons: breaking changes to ASTFactory methods (and client code):
         - makeASTRoot() and
         - addASTChild()

2. Provide a per-instance object pool
   Pros: fixes multi-threading issue, reduces ASTPair allocations
   Cons: future GCs may be more efficient, GC impact

3. Return to the pre-2.7.5 scheme and allow the GC to clean up.
   Pros: fixes multi-threading issue, leverages GC improvements
   Cons: more ASTPair allocations, GC impact

Any opinions?.

Cheers,

Micheal
ANTLR/C#






More information about the antlr-interest mailing list