[antlr-interest] ASTPair handling in C# runtime for 2.7.6
luisl at scarab.co.za
Wed Oct 26 13:18:06 PDT 2005
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.
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
For background info, pls see this thread:
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
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
More information about the antlr-interest