Question

We're running a .NET application that using this version of the parser in highly parallel manner. We are parsing single lines of input at a time on a given thread on which the parser/lexer is instantiated. Our implementation is using the recommended practice of first using an SLL strategy and falling back to LL if necessary.

After some amount of time (a few hours), our application becomes CPU bound. At which point we observe that most threads are waiting in these methods in :

public virtual DFAState GetTarget(int symbol)
{
    lock (this)
    {
        if (this.edges == null)
            return (DFAState) null;
        else
            return this.edges[symbol];
    }
}

public virtual void SetTarget(int symbol, DFAState target)
{
    lock (this)
    {
        if (this.edges == null)
            this.edges = (AbstractEdgeMap<DFAState>) new SingletonEdgeMap<DFAState>(this.minSymbol, this.maxSymbol);
        this.edges = this.edges.Put(symbol, target);
    }
}

It's our understanding that in this version, by default, DFA will not be used.

By default, the DFA will not be used for full-context parsing. This decision is due to substantial performance improvements such that the memory overhead of using the DFA for full-context parsing is no longer an obvious win. The old behavior can be enabled by setting parser.Interpreter.enable_global_context_dfa = true.

If this is true, why are we seeing this locks in the GetTarget() and SetTarget()? Do we have the correct runtime version: 4.2.2-alpha001?

Any insight here will be appreciated. Thanks.

Was it helpful?

Solution

The DFA is still used for SLL parsing.

You should post this as an issue on the project issue tracker. If you can provide example grammar and input, it would help immensely in locating a solution to your problems.

https://github.com/tunnelvisionlabs/antlr4cs/issues

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top