XText 2.12 blocking issues with Large Grammars [message #1770309] |
Wed, 09 August 2017 21:49 |
Joseph Landers Messages: 12 Registered: February 2017 |
Junior Member |
|
|
Hi there,
I'm working with Xtext 2.12 to try and create a DSL with a fairly large grammar. At first, I wasn't able to generate the infrastructure at all due to jvm out of memory errors. I was able to fix this by increasing the heap size in the jvm to 2gb via the flag -Xms2g (1 gig wasn't enough).
Anyway, after this I was able to generate the grammar, but the resulting files had errors as follows:
In my XxxxParser.java file - "The code of constructor x() is exceeding the 65535 bytes limit."
and in my InternalXxxxParser.java file "Too many constants, the constant pool for InternalXxxxParser would exceed 65536 entries."
Reading a few other posts led me to find Bug 34992 , which I read and mostly understood. ;-) Based on the recommendations in that ticket, I tried adding the following to my workflow:
fragment = parser.antlr.XtextAntlrGeneratorFragment2 auto-inject {
combinedGrammar = true // <-- I tried both true and false here. No luck.
options = {
classSplitting=true
fieldsPerClass = "500"
}
}
Note, the writeup in that ticket calls for using both parser.antlr.XtextAntlrGeneratorFragment and parser.antlr.XtextAntlrUIGeneratorFragment. However, neither of those classes are available to use, and parser.antlr.XtextAntlrGeneratorFragment2 is the closest thing I could find. Is there a replacement for parser.antlr.XtextAntlrUIGeneratorFragment?
Anyway, after adding the fragment above, the workflow is now failing with the following error:
[ERROR]: GeneratorException: (Element: -UNKNOWN-; Reported by: XtextGenerator)
java.lang.IllegalStateException: The given EMF object already contains an adapter for CombinedGrammarMarker
at org.eclipse.xtext.xtext.generator.parser.antlr.CombinedGrammarMarker.attachToEmfObject(CombinedGrammarMarker.java:66)
at org.eclipse.xtext.xtext.generator.parser.antlr.XtextAntlrGeneratorFragment2.doGenerate(XtextAntlrGeneratorFragment2.java:148)
at org.eclipse.xtext.xtext.generator.parser.antlr.AbstractAntlrGeneratorFragment2.generate(AbstractAntlrGeneratorFragment2.java:109)
at org.eclipse.xtext.xtext.generator.CompositeGeneratorFragment2.generate(CompositeGeneratorFragment2.java:50)
at org.eclipse.xtext.xtext.generator.XtextGenerator.invokeInternal(XtextGenerator.java:230)
at org.eclipse.emf.mwe.core.lib.AbstractWorkflowComponent.invoke(AbstractWorkflowComponent.java:126)
at org.eclipse.emf.mwe.core.lib.Mwe2Bridge.invoke(Mwe2Bridge.java:34)
at org.eclipse.emf.mwe.core.lib.AbstractWorkflowComponent.invoke(AbstractWorkflowComponent.java:201)
at org.eclipse.emf.mwe2.runtime.workflow.AbstractCompositeWorkflowComponent.invoke(AbstractCompositeWorkflowComponent.java:35)
at org.eclipse.emf.mwe2.runtime.workflow.Workflow.run(Workflow.java:19)
at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:102)
at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:62)
at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:52)
at org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher.run(Mwe2Launcher.java:78)
at org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher.main(Mwe2Launcher.java:36)
I don't fully understand the error, but since it's complaining about a duplicate adapter for "CombinedGrammarMarker" I tried twiddling the "combinedGrammar" flag in my config, but neither setting it to true nor false made any difference.
What do I have to do to get around these 64k errors?
- In my xxxParser.java file - "The code of constructor x() is exceeding the 65535 bytes limit."
- and in my InternalXxxParser.java file "Too many constants, the constant pool for InternalHtmlParser would exceed 65536 entries."
If using classSpliting = true is no longer supported, what else can I do? If this is still the correct way to get around these issues, what am I missing?
Thanks!
|
|
|
|
|
|
|
|
|
Re: XText 2.12 blocking issues with Large Grammars [message #1770329 is a reply to message #1770318] |
Thu, 10 August 2017 05:28 |
|
the following generation pattern would fix the issue
@Override
protected String getRuleName(AbstractElement element) {
if (nameMappings == null) {
nameMappings = new HashMap<AbstractElement, String>() {
private static final long serialVersionUID = 1L;
{
fillMap0();
fillMap1();
fillMap2();
fillMap3();
}
private void fillMap0() {
put(grammarAccess.getGreetingAccess().getGroup(), "rule__Greeting__Group__0");
put(grammarAccess.getModelAccess().getGreetingsAssignment(), "rule__Model__GreetingsAssignment");
put(grammarAccess.getGreetingAccess().getName1Assignment_1(), "rule__Greeting__Name1Assignment_1");
}
private void fillMap1() {
put(grammarAccess.getGreetingAccess().getName2Assignment_2(), "rule__Greeting__Name2Assignment_2");
put(grammarAccess.getGreetingAccess().getName3Assignment_3(), "rule__Greeting__Name3Assignment_3");
put(grammarAccess.getGreetingAccess().getName4Assignment_4(), "rule__Greeting__Name4Assignment_4");
}
private void fillMap2() {
put(grammarAccess.getGreetingAccess().getName5Assignment_5(), "rule__Greeting__Name5Assignment_5");
put(grammarAccess.getGreetingAccess().getName6Assignment_6(), "rule__Greeting__Name6Assignment_6");
put(grammarAccess.getGreetingAccess().getName7Assignment_7(), "rule__Greeting__Name7Assignment_7");
}
private void fillMap3() {
put(grammarAccess.getGreetingAccess().getName8Assignment_8(), "rule__Greeting__Name8Assignment_8");
put(grammarAccess.getGreetingAccess().getName9Assignment_9(), "rule__Greeting__Name9Assignment_9");
put(grammarAccess.getGreetingAccess().getName0Assignment_10(), "rule__Greeting__Name0Assignment_10");
}
};
}
return nameMappings.get(element);
}
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
|
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04242 seconds