Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Using Xbase in own grammar
Using Xbase in own grammar [message #691468] Fri, 01 July 2011 09:26 Go to next message
Eclipse User
Originally posted by:

Hi,

I'm still struggling with Xbase, but at least my setup seems to be
correct now. Now I consistently get out of heap error:

at
org.eclipse.xtext.generator.parser.antlr.AntlrToolFacade.runWithParams(AntlrToolFacade.java:132)
... 16 more
Caused by: java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2786)
at sun.misc.Resource.getBytes(Resource.java:101)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:257)

I suppose this is because the grammar becomes too large, although my
grammar does only contain 10 or so rules, with only two references to
XExpression.

I can set the heap size with the mx option to 1536 mb, but if I try
2048, the MacOSX (Snow Leopard) Java VM will not start.

Now I wonder what strategies I can use to make the grammar "smaller" in
a way that will make the generator survive.

One option is to remove features of the language, e.g. by redefining the
rule for XPrimaryExpression or XLiteral. E.g. if I include the following
rule I don't run out of memory:

XPrimaryExpression returns xbase::XExpression:
XConstructorCall |
XBlockExpression |
// XSwitchExpression |
XFeatureCall |
XLiteral |
XIfExpression |
// XForLoopExpression |
// XWhileExpression |
// XDoWhileExpression |
// XThrowExpression |
// XReturnExpression |
// XTryCatchFinallyExpression |
XParenthesizedExpression;

However, this will reduce the whole Xbase language, not specific usages
in some (problematic) contexts.

Another option is to make my own rules refer to special subclasses of
XExpression, to limit the legal constructs on that context. E.g. if I
only want simple expressions, I could refer to XOrExpression, which
disallows assignments. But this will still allow blocks etc.

Of course a combination of these two strategies are possible, but it's
difficult to find a balance between crippling the whole language (which
is nice, BTW) and limiting the options in contexts where grammar
ambiguities occur. In the extreme you could define several sub-languages
with different power that can be used on parallel, but this will of
course make the grammar large (text-wise) and difficult to maintain.

Comments, advice or interesting discussions are welcome!

Hallvard
Re: Using Xbase in own grammar [message #692066 is a reply to message #691468] Sun, 03 July 2011 07:20 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1761
Registered: July 2009
Senior Member
Documentation about Xbase and how to integarte it into your langauge
will be made available within the next couple of days.
Could you please open a bug and add a reproducable example for the
memory issue?

Sven

Am 7/1/11 3:26 PM, schrieb Hallvard Trætteberg:
> Hi,
>
> I'm still struggling with Xbase, but at least my setup seems to be
> correct now. Now I consistently get out of heap error:
>
> at
> org.eclipse.xtext.generator.parser.antlr.AntlrToolFacade.runWithParams(AntlrToolFacade.java:132)
>
> ... 16 more
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2786)
> at sun.misc.Resource.getBytes(Resource.java:101)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:257)
>
> I suppose this is because the grammar becomes too large, although my
> grammar does only contain 10 or so rules, with only two references to
> XExpression.
>
> I can set the heap size with the mx option to 1536 mb, but if I try
> 2048, the MacOSX (Snow Leopard) Java VM will not start.
>
> Now I wonder what strategies I can use to make the grammar "smaller" in
> a way that will make the generator survive.
>
> One option is to remove features of the language, e.g. by redefining the
> rule for XPrimaryExpression or XLiteral. E.g. if I include the following
> rule I don't run out of memory:
>
> XPrimaryExpression returns xbase::XExpression:
> XConstructorCall |
> XBlockExpression |
> // XSwitchExpression |
> XFeatureCall |
> XLiteral |
> XIfExpression |
> // XForLoopExpression |
> // XWhileExpression |
> // XDoWhileExpression |
> // XThrowExpression |
> // XReturnExpression |
> // XTryCatchFinallyExpression |
> XParenthesizedExpression;
>
> However, this will reduce the whole Xbase language, not specific usages
> in some (problematic) contexts.
>
> Another option is to make my own rules refer to special subclasses of
> XExpression, to limit the legal constructs on that context. E.g. if I
> only want simple expressions, I could refer to XOrExpression, which
> disallows assignments. But this will still allow blocks etc.
>
> Of course a combination of these two strategies are possible, but it's
> difficult to find a balance between crippling the whole language (which
> is nice, BTW) and limiting the options in contexts where grammar
> ambiguities occur. In the extreme you could define several sub-languages
> with different power that can be used on parallel, but this will of
> course make the grammar large (text-wise) and difficult to maintain.
>
> Comments, advice or interesting discussions are welcome!
>
> Hallvard


--
Need professional support for Xtext or other Eclipse Modeling technologies?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : http://blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: Using Xbase in own grammar [message #692411 is a reply to message #692066] Mon, 04 July 2011 07:34 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan Koehnlein
Messages: 656
Registered: July 2009
Senior Member
I've just updated the online docs and added a chapter on Xbase and Java
integration. You might find this helpful:

http://www.eclipse.org/Xtext/documentation/2_0_0/199-xtext-and-java.php


Am 03.07.11 13:20, schrieb Sven Efftinge:
> Documentation about Xbase and how to integarte it into your langauge
> will be made available within the next couple of days.
> Could you please open a bug and add a reproducable example for the
> memory issue?
>
> Sven
>
> Am 7/1/11 3:26 PM, schrieb Hallvard Trætteberg:
>> Hi,
>>
>> I'm still struggling with Xbase, but at least my setup seems to be
>> correct now. Now I consistently get out of heap error:
>>
>> at
>> org.eclipse.xtext.generator.parser.antlr.AntlrToolFacade.runWithParams(AntlrToolFacade.java:132)
>>
>> ... 16 more
>> Caused by: java.lang.OutOfMemoryError: Java heap space
>> at java.util.Arrays.copyOf(Arrays.java:2786)
>> at sun.misc.Resource.getBytes(Resource.java:101)
>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:257)
>>
>> I suppose this is because the grammar becomes too large, although my
>> grammar does only contain 10 or so rules, with only two references to
>> XExpression.
>>
>> I can set the heap size with the mx option to 1536 mb, but if I try
>> 2048, the MacOSX (Snow Leopard) Java VM will not start.
>>
>> Now I wonder what strategies I can use to make the grammar "smaller" in
>> a way that will make the generator survive.
>>
>> One option is to remove features of the language, e.g. by redefining the
>> rule for XPrimaryExpression or XLiteral. E.g. if I include the following
>> rule I don't run out of memory:
>>
>> XPrimaryExpression returns xbase::XExpression:
>> XConstructorCall |
>> XBlockExpression |
>> // XSwitchExpression |
>> XFeatureCall |
>> XLiteral |
>> XIfExpression |
>> // XForLoopExpression |
>> // XWhileExpression |
>> // XDoWhileExpression |
>> // XThrowExpression |
>> // XReturnExpression |
>> // XTryCatchFinallyExpression |
>> XParenthesizedExpression;
>>
>> However, this will reduce the whole Xbase language, not specific usages
>> in some (problematic) contexts.
>>
>> Another option is to make my own rules refer to special subclasses of
>> XExpression, to limit the legal constructs on that context. E.g. if I
>> only want simple expressions, I could refer to XOrExpression, which
>> disallows assignments. But this will still allow blocks etc.
>>
>> Of course a combination of these two strategies are possible, but it's
>> difficult to find a balance between crippling the whole language (which
>> is nice, BTW) and limiting the options in contexts where grammar
>> ambiguities occur. In the extreme you could define several sub-languages
>> with different power that can be used on parallel, but this will of
>> course make the grammar large (text-wise) and difficult to maintain.
>>
>> Comments, advice or interesting discussions are welcome!
>>
>> Hallvard
>
>


--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: Using Xbase in own grammar [message #692413 is a reply to message #692411] Mon, 04 July 2011 07:44 Go to previous message
Eclipse User
Originally posted by:

On 04.07.11 13.34, Jan Koehnlein wrote:
> I've just updated the online docs and added a chapter on Xbase and Java
> integration. You might find this helpful:
>
> http://www.eclipse.org/Xtext/documentation/2_0_0/199-xtext-and-java.php

Great! I'll most likely create an example project, where I experiment
with various constructs that utilize and extend Xbase in various ways.
So far, I've defined two new operators and mapped them to XXXExtensions
class methods. The next steps are inferring Jvm elements from constructs
that first map to Ecore and then to Jvm elements (as if generated by a
genmodel).

Pity I'm off for summer vacation, now :-)

Hallvard

>
>
> Am 03.07.11 13:20, schrieb Sven Efftinge:
>> Documentation about Xbase and how to integarte it into your langauge
>> will be made available within the next couple of days.
>> Could you please open a bug and add a reproducable example for the
>> memory issue?
>>
>> Sven
>>
>> Am 7/1/11 3:26 PM, schrieb Hallvard Trætteberg:
>>> Hi,
>>>
>>> I'm still struggling with Xbase, but at least my setup seems to be
>>> correct now. Now I consistently get out of heap error:
>>>
>>> at
>>> org.eclipse.xtext.generator.parser.antlr.AntlrToolFacade.runWithParams(AntlrToolFacade.java:132)
>>>
>>>
>>> ... 16 more
>>> Caused by: java.lang.OutOfMemoryError: Java heap space
>>> at java.util.Arrays.copyOf(Arrays.java:2786)
>>> at sun.misc.Resource.getBytes(Resource.java:101)
>>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:257)
>>>
>>> I suppose this is because the grammar becomes too large, although my
>>> grammar does only contain 10 or so rules, with only two references to
>>> XExpression.
>>>
>>> I can set the heap size with the mx option to 1536 mb, but if I try
>>> 2048, the MacOSX (Snow Leopard) Java VM will not start.
>>>
>>> Now I wonder what strategies I can use to make the grammar "smaller" in
>>> a way that will make the generator survive.
>>>
>>> One option is to remove features of the language, e.g. by redefining the
>>> rule for XPrimaryExpression or XLiteral. E.g. if I include the following
>>> rule I don't run out of memory:
>>>
>>> XPrimaryExpression returns xbase::XExpression:
>>> XConstructorCall |
>>> XBlockExpression |
>>> // XSwitchExpression |
>>> XFeatureCall |
>>> XLiteral |
>>> XIfExpression |
>>> // XForLoopExpression |
>>> // XWhileExpression |
>>> // XDoWhileExpression |
>>> // XThrowExpression |
>>> // XReturnExpression |
>>> // XTryCatchFinallyExpression |
>>> XParenthesizedExpression;
>>>
>>> However, this will reduce the whole Xbase language, not specific usages
>>> in some (problematic) contexts.
>>>
>>> Another option is to make my own rules refer to special subclasses of
>>> XExpression, to limit the legal constructs on that context. E.g. if I
>>> only want simple expressions, I could refer to XOrExpression, which
>>> disallows assignments. But this will still allow blocks etc.
>>>
>>> Of course a combination of these two strategies are possible, but it's
>>> difficult to find a balance between crippling the whole language (which
>>> is nice, BTW) and limiting the options in contexts where grammar
>>> ambiguities occur. In the extreme you could define several sub-languages
>>> with different power that can be used on parallel, but this will of
>>> course make the grammar large (text-wise) and difficult to maintain.
>>>
>>> Comments, advice or interesting discussions are welcome!
>>>
>>> Hallvard
>>
>>
>
>
Previous Topic:Integrating Xbase with EMF and own language
Next Topic:Synchronize Xtext and GMF editors
Goto Forum:
  


Current Time: Thu Aug 21 00:28:10 EDT 2014

Powered by FUDForum. Page generated in 0.02620 seconds