Home » Modeling » EMF » StackOverflowError with package initialization "by loading"
| StackOverflowError with package initialization "by loading" [message #421159] |
Tue, 29 July 2008 12:21  |
 JG
Messages: 51
Registered: July 2009 |
Member |
|
|
Hi,
one of my packages (or maybe my entire model, not sure) has apparently
just reached the point where the code generator considers the init()
method (or is it actually the createPackageContent() method?) that would
result for its XYZPackageImpl to get too big to fit within the
64k-code-per-method limit of Java.
As a result, I stumbled upon a number of issues, which I could resolve
or at least circumvent to some extent, but I feat that this fix is more
a temporary one.
I first noted that this had happened when suddenly after regenerating
the code, my application would throw an ExceptionInInitializerError
directly upon start... the .ecore file needed for "initialize by
loading" had not been copied to my project's bin directory, as *.ecore
was set as an "excluded resource" in my Eclipse's default built options.
After resolving that issue, I was greeted with a NullPointerException...
I looked at the loadPackage() method that had been generated, and
found that the load code didn't like empty packages (which I had used to
"structure" my packages). After adding a dummy datatype to each empty
package, I had high hopes of having resolved all problems, but I now get
a StackOverflowError:
Exception in thread "main" java.lang.StackOverflowError
at org.eclipse.emf.common.util.BasicEList.get(BasicEList.java:5 37)
at
org.eclipse.emf.ecore.impl.EOperationImpl.freeze(EOperationI mpl.java:124)
at
org.eclipse.emf.ecore.impl.EModelElementImpl.freeze(EModelEl ementImpl.java:92)
at org.eclipse.emf.ecore.impl.EClassImpl.freeze(EClassImpl.java :146)
at
org.eclipse.emf.ecore.impl.EModelElementImpl.freeze(EModelEl ementImpl.java:92)
at org.eclipse.emf.ecore.impl.EPackageImpl.freeze(EPackageImpl. java:179)
at
org.eclipse.emf.ecore.impl.EModelElementImpl.freeze(EModelEl ementImpl.java:92)
at org.eclipse.emf.ecore.impl.EPackageImpl.freeze(EPackageImpl. java:186)
at
org.eclipse.emf.ecore.impl.EModelElementImpl.freeze(EModelEl ementImpl.java:92)
at org.eclipse.emf.ecore.impl.EPackageImpl.freeze(EPackageImpl. java:186)
at
org.eclipse.emf.ecore.impl.EModelElementImpl.freeze(EModelEl ementImpl.java:92)
at org.eclipse.emf.ecore.impl.EPackageImpl.freeze(EPackageImpl. java:186)
at
org.eclipse.emf.ecore.impl.EModelElementImpl.freeze(EModelEl ementImpl.java:92)
at org.eclipse.emf.ecore.impl.EPackageImpl.freeze(EPackageImpl. java:186)
[...]
I find it difficult to debug this one (Eclipse Debugger would hang,
marking the Thread as "not responding"), and even if I could, I doubt
that I could work around the problem once more.
I circumvented this problem for the moment by setting "Initialize by
loading" to false in the genmodel for my problematic package. At the
moment, my code still compiles, but I have no idea how much "headroom"
is left to the 64k-per-method limit. Since I am still extending the
model and the package in question, I am a bit worried that this
workaround would not hold on for much longer.
So that's why I am comming to the newsgroup to investigate my
StackOverflowError a bit more:
Is this a known problem, is there a way to circumvent it?
Would splitting the problematic package into different subpackages help
to get away from the 64k limit, i.e., is the limit a "per package" or
more a "per model" limit? It seems that createPackageContent() method is
the problem, as this is the one being replaced by the loadPackage
method, so I guess distributing my classes across several packages I
could reliably work around the problem entirely. Could someone confirm
this assumption?
I also found a bug marked as fixed which could relate to this problem:
"StackOverflowError with large EMF models"
https://bugs.eclipse.org/bugs/show_bug.cgi?id=131674
Is this referring to the same problem?
BTW, I am using EMF 2.3.1.v200802051830.
Regards
JG
|
|
|
| Re: StackOverflowError with package initialization "by loading" [message #421185 is a reply to message #421159] |
Tue, 29 July 2008 21:29  |
David Steinberg
Messages: 489
Registered: July 2009 |
Senior Member |
|
|
JG wrote:
>
> one of my packages (or maybe my entire model, not sure) has apparently
> just reached the point where the code generator considers the init()
> method (or is it actually the createPackageContent() method?) that would
> result for its XYZPackageImpl to get too big to fit within the
> 64k-code-per-method limit of Java.
> As a result, I stumbled upon a number of issues, which I could resolve
> or at least circumvent to some extent, but I feat that this fix is more
> a temporary one.
Hi JG,
The heuristic used to recognize a "big" model and set the "Initialize by
Loading" property is very rough and hasn't been tuned at all. You might
very well have lots of room to expand your model before hitting the 64k
limit. I'd encourage you to stick with the non-loading pattern until you
find that your package class won't compile anymore.
That said, the issues you ran into are certainly valid. The loading
pattern *should* work...
> I first noted that this had happened when suddenly after regenerating
> the code, my application would throw an ExceptionInInitializerError
> directly upon start... the .ecore file needed for "initialize by
> loading" had not been copied to my project's bin directory, as *.ecore
> was set as an "excluded resource" in my Eclipse's default built options.
I really don't know how this one happened. I haven't experienced that,
as I find that only *.launch is excluded by default.
> After resolving that issue, I was greeted with a NullPointerException...
> I looked at the loadPackage() method that had been generated, and found
> that the load code didn't like empty packages (which I had used to
> "structure" my packages).
I just tried out a simple model with nested empty packages, and I'm
seeing a couple of different problems. If there's a package that's
contained only by empty packages, the empty packages get dropped from
the GenModel, but still get serialized, so what the generated
loadPackage() finds is not what it expects. This is easy enough to fix:
we'd just need serialize the first non-empty package in the resource root.
I'm also seeing problems with an empty package between two non-empty
packages. There's no generated package for the empty one, and hence
nothing registered in the package registry, but the intialization code
expects one. I'm not sure how best to fix this; I'd want to compare it
to what happens in the non-loading pattern.
Please open a bug for this (include a link back to this thread) and
we'll fix it.
After adding a dummy datatype to each empty
> package, I had high hopes of having resolved all problems, but I now get
> a StackOverflowError:
This one I can't reproduce. Adding an EDataType to each empty package to
make it non-empty resolves the problems for me. If you open a bug,
please include a test case that allows us to reproduce it.
> Would splitting the problematic package into different subpackages help
> to get away from the 64k limit, i.e., is the limit a "per package" or
> more a "per model" limit? It seems that createPackageContent() method is
> the problem, as this is the one being replaced by the loadPackage
> method, so I guess distributing my classes across several packages I
> could reliably work around the problem entirely. Could someone confirm
> this assumption?
That's right. The limitation is per-package, not per-model. Splitting up
big packages is a way to avoid it entirely.
> I also found a bug marked as fixed which could relate to this problem:
>
> "StackOverflowError with large EMF models"
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=131674
> Is this referring to the same problem?
No, that looks to be unrelated. And fixed. ;)
Cheers,
Dave
|
|
|
| Re: StackOverflowError with package initialization "by loading" [message #421187 is a reply to message #421185] |
Wed, 30 July 2008 00:51 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Dave,
I would be nice if EMF could support the completely general case of
nesting packages, empty or not, for generated and loaded packages alike.
It is quite common for metamodels to be specified with package
hierarchies including empty packages at all but the leaf levels. If
Ecore is to supplant MOF for the 3.0 version, I could see this being
important. Just look at all of the OMG metamodels that have this structure.
Cheers,
Christian
Dave Steinberg wrote:
> JG wrote:
>>
>> one of my packages (or maybe my entire model, not sure) has apparently
>> just reached the point where the code generator considers the init()
>> method (or is it actually the createPackageContent() method?) that
>> would result for its XYZPackageImpl to get too big to fit within the
>> 64k-code-per-method limit of Java.
>> As a result, I stumbled upon a number of issues, which I could resolve
>> or at least circumvent to some extent, but I feat that this fix is
>> more a temporary one.
>
> Hi JG,
>
> The heuristic used to recognize a "big" model and set the "Initialize by
> Loading" property is very rough and hasn't been tuned at all. You might
> very well have lots of room to expand your model before hitting the 64k
> limit. I'd encourage you to stick with the non-loading pattern until you
> find that your package class won't compile anymore.
>
> That said, the issues you ran into are certainly valid. The loading
> pattern *should* work...
>
>> I first noted that this had happened when suddenly after regenerating
>> the code, my application would throw an ExceptionInInitializerError
>> directly upon start... the .ecore file needed for "initialize by
>> loading" had not been copied to my project's bin directory, as *.ecore
>> was set as an "excluded resource" in my Eclipse's default built options.
>
> I really don't know how this one happened. I haven't experienced that,
> as I find that only *.launch is excluded by default.
>
>> After resolving that issue, I was greeted with a
>> NullPointerException... I looked at the loadPackage() method that had
>> been generated, and found that the load code didn't like empty
>> packages (which I had used to "structure" my packages).
>
> I just tried out a simple model with nested empty packages, and I'm
> seeing a couple of different problems. If there's a package that's
> contained only by empty packages, the empty packages get dropped from
> the GenModel, but still get serialized, so what the generated
> loadPackage() finds is not what it expects. This is easy enough to fix:
> we'd just need serialize the first non-empty package in the resource root.
>
> I'm also seeing problems with an empty package between two non-empty
> packages. There's no generated package for the empty one, and hence
> nothing registered in the package registry, but the intialization code
> expects one. I'm not sure how best to fix this; I'd want to compare it
> to what happens in the non-loading pattern.
>
> Please open a bug for this (include a link back to this thread) and
> we'll fix it.
>
> After adding a dummy datatype to each empty
>> package, I had high hopes of having resolved all problems, but I now
>> get a StackOverflowError:
>
> This one I can't reproduce. Adding an EDataType to each empty package to
> make it non-empty resolves the problems for me. If you open a bug,
> please include a test case that allows us to reproduce it.
>
>> Would splitting the problematic package into different subpackages
>> help to get away from the 64k limit, i.e., is the limit a "per
>> package" or more a "per model" limit? It seems that
>> createPackageContent() method is the problem, as this is the one being
>> replaced by the loadPackage method, so I guess distributing my classes
>> across several packages I could reliably work around the problem
>> entirely. Could someone confirm this assumption?
>
> That's right. The limitation is per-package, not per-model. Splitting up
> big packages is a way to avoid it entirely.
>
>> I also found a bug marked as fixed which could relate to this problem:
>>
>> "StackOverflowError with large EMF models"
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=131674
>> Is this referring to the same problem?
>
> No, that looks to be unrelated. And fixed. ;)
>
> Cheers,
> Dave
|
|
|
| Re: StackOverflowError with package initialization "by loading" [message #421189 is a reply to message #421187] |
Wed, 30 July 2008 03:34 |
David Steinberg
Messages: 489
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
I agree. I'm not aware of any problems with Ecore models containing
nested empty or non-empty packages. The problem here is that our model
importers strip out the empty packages (and replace them by a
GenPackage.basePackage value) but the generator pattern that uses
loading for package initialization fails to account for that properly.
I don't think the empty packages really get you anything, so it seems
useful enough to strip them as we do. Are you suggesting that we
shouldn't do that, or just emphasizing that we should work out this bug?
Or do you know of other problems?
Cheers,
Dave
Christian W. Damus wrote:
> Hi, Dave,
>
> I would be nice if EMF could support the completely general case of
> nesting packages, empty or not, for generated and loaded packages alike.
> It is quite common for metamodels to be specified with package
> hierarchies including empty packages at all but the leaf levels. If
> Ecore is to supplant MOF for the 3.0 version, I could see this being
> important. Just look at all of the OMG metamodels that have this
> structure.
>
> Cheers,
>
> Christian
>
>
> Dave Steinberg wrote:
>> JG wrote:
>>>
>>> one of my packages (or maybe my entire model, not sure) has
>>> apparently just reached the point where the code generator considers
>>> the init() method (or is it actually the createPackageContent()
>>> method?) that would result for its XYZPackageImpl to get too big to
>>> fit within the 64k-code-per-method limit of Java.
>>> As a result, I stumbled upon a number of issues, which I could
>>> resolve or at least circumvent to some extent, but I feat that this
>>> fix is more a temporary one.
>>
>> Hi JG,
>>
>> The heuristic used to recognize a "big" model and set the "Initialize
>> by Loading" property is very rough and hasn't been tuned at all. You
>> might very well have lots of room to expand your model before hitting
>> the 64k limit. I'd encourage you to stick with the non-loading pattern
>> until you find that your package class won't compile anymore.
>>
>> That said, the issues you ran into are certainly valid. The loading
>> pattern *should* work...
>>
>>> I first noted that this had happened when suddenly after regenerating
>>> the code, my application would throw an ExceptionInInitializerError
>>> directly upon start... the .ecore file needed for "initialize by
>>> loading" had not been copied to my project's bin directory, as
>>> *.ecore was set as an "excluded resource" in my Eclipse's default
>>> built options.
>>
>> I really don't know how this one happened. I haven't experienced that,
>> as I find that only *.launch is excluded by default.
>>
>>> After resolving that issue, I was greeted with a
>>> NullPointerException... I looked at the loadPackage() method that
>>> had been generated, and found that the load code didn't like empty
>>> packages (which I had used to "structure" my packages).
>>
>> I just tried out a simple model with nested empty packages, and I'm
>> seeing a couple of different problems. If there's a package that's
>> contained only by empty packages, the empty packages get dropped from
>> the GenModel, but still get serialized, so what the generated
>> loadPackage() finds is not what it expects. This is easy enough to
>> fix: we'd just need serialize the first non-empty package in the
>> resource root.
>>
>> I'm also seeing problems with an empty package between two non-empty
>> packages. There's no generated package for the empty one, and hence
>> nothing registered in the package registry, but the intialization code
>> expects one. I'm not sure how best to fix this; I'd want to compare it
>> to what happens in the non-loading pattern.
>>
>> Please open a bug for this (include a link back to this thread) and
>> we'll fix it.
>>
>> After adding a dummy datatype to each empty
>>> package, I had high hopes of having resolved all problems, but I now
>>> get a StackOverflowError:
>>
>> This one I can't reproduce. Adding an EDataType to each empty package
>> to make it non-empty resolves the problems for me. If you open a bug,
>> please include a test case that allows us to reproduce it.
>>
>>> Would splitting the problematic package into different subpackages
>>> help to get away from the 64k limit, i.e., is the limit a "per
>>> package" or more a "per model" limit? It seems that
>>> createPackageContent() method is the problem, as this is the one
>>> being replaced by the loadPackage method, so I guess distributing my
>>> classes across several packages I could reliably work around the
>>> problem entirely. Could someone confirm this assumption?
>>
>> That's right. The limitation is per-package, not per-model. Splitting
>> up big packages is a way to avoid it entirely.
>>
>>> I also found a bug marked as fixed which could relate to this problem:
>>>
>>> "StackOverflowError with large EMF models"
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=131674
>>> Is this referring to the same problem?
>>
>> No, that looks to be unrelated. And fixed. ;)
>>
>> Cheers,
>> Dave
|
|
| |
| Re: StackOverflowError with package initialization "by loading" [message #421192 is a reply to message #421185] |
Wed, 30 July 2008 05:59 |
JG
Messages: 51
Registered: July 2009 |
Member |
|
|
Hi Dave,
Dave Steinberg wrote:
> The heuristic used to recognize a "big" model and set the "Initialize by
> Loading" property is very rough and hasn't been tuned at all. You might
> very well have lots of room to expand your model before hitting the 64k
> limit. I'd encourage you to stick with the non-loading pattern until you
> find that your package class won't compile anymore.
Okay, and I will keep my fingers crossed.
> I really don't know how this one happened. I haven't experienced that,
> as I find that only *.launch is excluded by default.
Inmy Eclipse installation, the list of excluded resources is much longer
(but was never manually edited by me). I guess some plugins contributed
to it (as I can trace the *.g extension to the ANTLR plugin), but who or
what added *.ecore files? Maybe some plugin depending on EMF? I have or
had used GEF, GMF, UML2, Teneo and probably others I can't remember
right now.
> I just tried out a simple model with nested empty packages, and I'm
> seeing a couple of different problems. If there's a package that's
> contained only by empty packages, the empty packages get dropped from
> the GenModel, but still get serialized, so what the generated
> loadPackage() finds is not what it expects. This is easy enough to fix:
> we'd just need serialize the first non-empty package in the resource root.
>
> I'm also seeing problems with an empty package between two non-empty
> packages. There's no generated package for the empty one, and hence
> nothing registered in the package registry, but the intialization code
> expects one. I'm not sure how best to fix this; I'd want to compare it
> to what happens in the non-loading pattern.
I actually had both issues in my model... an empty root package, and
empty intermediate packages. But IIRC both showed up as the same error,
when looking up the empty package in the package registry would yield a
null.
> Please open a bug for this (include a link back to this thread) and
> we'll fix it.
I just did that,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=242494
> After adding a dummy datatype to each empty
>> package, I had high hopes of having resolved all problems, but I now
>> get a StackOverflowError:
>
> This one I can't reproduce. Adding an EDataType to each empty package to
> make it non-empty resolves the problems for me. If you open a bug,
> please include a test case that allows us to reproduce it.
I will try my very best to provide a test case, but I can't guarantee I
can get you one. I will have quite some obfuscating to do in my model
(not so much due to the great value of the intellectual property
contained therein, but more due to my embarassingly terrible design...
the model is one of those "skeletons in the closet" type of things... ;-) ).
>> Would splitting the problematic package into different subpackages
>> help to get away from the 64k limit, i.e., is the limit a "per
>> package" or more a "per model" limit? It seems that
>> createPackageContent() method is the problem, as this is the one being
>> replaced by the loadPackage method, so I guess distributing my classes
>> across several packages I could reliably work around the problem
>> entirely. Could someone confirm this assumption?
>
> That's right. The limitation is per-package, not per-model. Splitting up
> big packages is a way to avoid it entirely.
I guess for my part I could live with that workaround for a while, but I
second the remarks by Christian (who is involved in the UML2 project,
IIRC) in reply to your posting.
Regards
JG
|
|
| |
| Re: StackOverflowError with package initialization "by loading" [message #421201 is a reply to message #421189] |
Wed, 30 July 2008 13:12 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Dave,
I may be taking this thread on a tangent; sorry about that.
I'm just thinking of my experience with the OCL metamodel, in which I
have this structure
- OCL
- Types
... eclassifiers
- Expressions
... eclassifiers
...
IOW, the root package is "empty" (having no classifiers) and thus only
serves as a namespace to gather sub-packages. This metamodel is
generated statically (no loading).
The problem is, that the EPackage.Registry doesn't include the OCL
package and the Types and Expressions packages don't know that they have
a containing package. This means that qualified name look-ups in
languages like OCL, itself, don't work because the registry doesn't have
all of the namespace information.
I actually worked around this by hacking the OCL package into the
registry and parentage of the others at run-time, when initializing the
packages. This works for OCL because it's the first thing that OCL
does, anyway. :-)
Generally speaking, it would be nice to begin treating packages that
don't have EClassifiers like other packages in every respect.
Cheers,
Christian
Dave Steinberg wrote:
> Hi Christian,
>
> I agree. I'm not aware of any problems with Ecore models containing
> nested empty or non-empty packages. The problem here is that our model
> importers strip out the empty packages (and replace them by a
> GenPackage.basePackage value) but the generator pattern that uses
> loading for package initialization fails to account for that properly.
>
> I don't think the empty packages really get you anything, so it seems
> useful enough to strip them as we do. Are you suggesting that we
> shouldn't do that, or just emphasizing that we should work out this bug?
> Or do you know of other problems?
>
> Cheers,
> Dave
>
>
> Christian W. Damus wrote:
>> Hi, Dave,
>>
>> I would be nice if EMF could support the completely general case of
>> nesting packages, empty or not, for generated and loaded packages
>> alike. It is quite common for metamodels to be specified with package
>> hierarchies including empty packages at all but the leaf levels. If
>> Ecore is to supplant MOF for the 3.0 version, I could see this being
>> important. Just look at all of the OMG metamodels that have this
>> structure.
>>
>> Cheers,
>>
>> Christian
-----8<-----
|
|
| |
| Re: StackOverflowError with package initialization "by loading" [message #421205 is a reply to message #421201] |
Wed, 30 July 2008 14:51 |
David Steinberg
Messages: 489
Registered: July 2009 |
Senior Member |
|
|
Hi again Christian,
I can see how that could be handy when you have multiple nested packages
that you'd like to access from a common parent. I'd imagine we could
decide whether to create and register empty packages or collapse them
into a basePackage based on whether there's a namespace URI present. I'd
have to investigate further to be sure that it would be work, but it
surely seems reasonable.
Cheers,
Dave
Christian W. Damus wrote:
> Hi, Dave,
>
> I may be taking this thread on a tangent; sorry about that.
>
> I'm just thinking of my experience with the OCL metamodel, in which I
> have this structure
>
> - OCL
> - Types
> ... eclassifiers
> - Expressions
> ... eclassifiers
> ...
>
> IOW, the root package is "empty" (having no classifiers) and thus only
> serves as a namespace to gather sub-packages. This metamodel is
> generated statically (no loading).
>
> The problem is, that the EPackage.Registry doesn't include the OCL
> package and the Types and Expressions packages don't know that they have
> a containing package. This means that qualified name look-ups in
> languages like OCL, itself, don't work because the registry doesn't have
> all of the namespace information.
>
> I actually worked around this by hacking the OCL package into the
> registry and parentage of the others at run-time, when initializing the
> packages. This works for OCL because it's the first thing that OCL
> does, anyway. :-)
>
> Generally speaking, it would be nice to begin treating packages that
> don't have EClassifiers like other packages in every respect.
>
> Cheers,
>
> Christian
|
|
|
| Re: StackOverflowError with package initialization "by loading" [message #421214 is a reply to message #421205] |
Wed, 30 July 2008 20:51 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Dave,
That sounds like a good idea. If there isn't a namespace URI, then the
package isn't "addressable" in the XMI sense nor, as is increasingly the
case, in the modeling sense. (I gather that namespace URI is becoming a
standard way to identify packages in repository-based systems, as well)
Thanks for the consideration. I have a test case ready in hand to help
with testing, at least ;-)
cW
Dave Steinberg wrote:
> Hi again Christian,
>
> I can see how that could be handy when you have multiple nested packages
> that you'd like to access from a common parent. I'd imagine we could
> decide whether to create and register empty packages or collapse them
> into a basePackage based on whether there's a namespace URI present. I'd
> have to investigate further to be sure that it would be work, but it
> surely seems reasonable.
>
> Cheers,
> Dave
>
>
-----8<-----
|
|
|
Goto Forum:
Current Time: Tue Apr 23 16:45:11 GMT 2024
Powered by FUDForum. Page generated in 0.03428 seconds |
] 
Search
Help
Register
Login
Home
