6

Lexer DFA 导致“代码太大”错误

我正在尝试使用 ANTLR 3 解析 Java 服务器页面。

Java 对单个方法的字节码有 64k 的限制，在编译 ANTLR 生成的 Java 源代码时，我一直遇到“代码太大”错误。

在某些情况下，我可以通过破坏我的词法分析器来修复它。例如，JSP 使用 XML“名称”标记，它可以包含多种字符。我决定在我的“名称”标记中只接受 ASCII 字符，这极大地简化了一些测试，并且词法分析器允许它编译。

但是，我已经到了不能再偷工减料的地步了，但是 DFA 仍然太复杂了。

我该怎么办？

是否存在导致复杂 DFA 的常见错误？

有没有办法抑制 DFA 的生成，也许依靠语义谓词或固定的前瞻来帮助预测？

手工编写这个词法分析器很容易，但在我放弃 ANTLR 之前，我想确保我没有忽略一些明显的东西。

背景

ANTLR 3 词法分析器使用 DFA 来决定如何标记输入。在生成的 DFA 中，有一个方法叫做specialStateTransition(). 此方法包含一个switch语句，其中包含 DFA 中每个状态的案例。在每种情况下，都有一系列if语句，每个语句用于状态转换。每个if语句的条件测试一个输入字符以查看它是否与转换匹配。

这些字符测试条件可能非常复杂。它们通常具有以下形式：

int ch = … ; /* "ch" is the next character in the input stream. */
switch(s) { /* "s" is the current state. */
  …
  case 13 :
    if ((('a' <= ch) && (ch <= 'z')) || (('A' <= ch) && (ch <= 'Z')) || … )
      s = 24; /* If the character matches, move to the next state. */
    else if …

对我的词法分析器的一个看似微小的更改可能会导致对单个转换、每个状态的多个转换和多个状态进行数十次比较。我认为由于我的语义谓词，某些正在考虑的状态是不可能达到的，但 DFA 似乎忽略了语义谓词。（不过我可能会误读——这段代码绝对不是我能手写的！）

我在 Jsp2x 工具中找到了一个 ANTLR 2 语法，但我对它的解析树不满意，我想刷新我的 ANTLR 技能，所以我想我会尝试自己编写。我正在使用 ANTLRWorks，并尝试为 DFA 生成图表，但 ANTLRWorks 中似乎存在阻止它的错误。

4

2 回答 2

4

非常大的语法（许多不同的标记）有这个问题，不幸的是（SQL 语法也有这个问题）。

有时可以通过制定某些词法分析器规则来解决此问题，这些fragments规则与产生标记的“完整”词法分析器规则相对，和/或重新安排字符在规则中的匹配方式，但是通过查看您已经尝试过的方式，我怀疑是否可以在你的情况下获得了很多。但是，如果您愿意在 SO 上发布您的词法分析器语法，我或其他人可能会看到可以更改的内容。

通常，通过将词法分析器语法拆分为 2 个或多个单独的词法分析器语法，然后将它们导入一个“主”语法来解决此问题。在 ANTLR 术语中，这些被称为复合文法。请参阅有关它们的 ANTLR Wiki 页面：http ://www.antlr.org/wiki/display/ANTLR3/Composite+Grammars

编辑

正如@Gunther 在 OP 下方的评论中正确提到的那样，请参阅问答：为什么我的 antlr lexer java 类“代码太大”？一个小的变化（删除某个谓词）导致这个“代码太大”错误消失。

于 2011-09-22T17:44:00.040 回答
3

好吧，实际上制作复合语法并不总是那么容易。在很多情况下，这个 AntTask有助于解决这个问题（每次重新编译语法后都必须运行它，但这个过程并不那么无聊）。

不幸的是，即使是这个神奇的脚本在某些复杂的情况下也无济于事。编译器可能会开始抱怨DFA 转换块过大（静态 String[] 字段）。

我找到了一种简单的方法来解决它，通过将这些字段移动（使用 IDE 重构功能）到另一个具有任意生成名称的类。当以这种方式移动一个或多个字段时，它总是有帮助的。

于 2012-09-18T18:22:13.793 回答