Home » Modeling » Papyrus » Limitations in the size of Papyrus models
|
| Re: Limitations in the size of Papyrus models [message #1717072 is a reply to message #1717053] |
Wed, 09 December 2015 19:38   |
|
Hi Nicola.
You can play with the -Xms and -Xmx values.
Changing these is one of the first things I do after installing Eclipse for modeling purposes and I never run with anything lower than:
-Xms512m
-Xmx2048m
You can go higher for larger models.
/Charles Rivet
|
|
|
| Re: Limitations in the size of Papyrus models [message #1717144 is a reply to message #1717072] |
Thu, 10 December 2015 09:26 |
 Camille Letavernier
Messages: 952
Registered: February 2011 |
Senior Member |
|
|
Hi Nicola,
-Xmx is the maximum amount of memory available to Java ("Heap space"), so that's the value you want to increase
Additionally, there are a few things to consider to improve scalability of your models:
- Use Sub-models (Fragments / Control Mode). This will improve lazy loading, but only until you call a refactoring operation that may impact the entire model (Such as deleting an element). So this should also be used with the "Papyrus > Model Loading" options for maximum efficiency
- Models themselves are not so expensive in memory. Diagrams are. Close the diagram tabs you don't use (Many users neglect this, and we're not able to automatically put the diagrams in 'sleep mode' yet). Closing diagrams will also improve the performances when opening your editor
- When an operation seems abnormally slow or memory-consuming, do not hesitate to report a bug to the Papyrus project: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus. We try to fix these bugs as soon as possible (Or give hints to avoid the most expensive operations)
HTH,
Camille
Camille Letavernier
[Updated on: Thu, 10 December 2015 09:26] Report message to a moderator |
|
|
| Re: Limitations in the size of Papyrus models [message #1717198 is a reply to message #1717144] |
Thu, 10 December 2015 17:08 |
Nicola Mazzacane
Messages: 21
Registered: September 2014 |
Junior Member |
|
|
Hi,
I have applied part of the suggested actions (increase memory resources, closing diagrams, etc.), but the result was not conclusive: after application of
repeatable changes (in general, new model items and filling of text in some properties of stereotypes), the model cannot be no longer opened if the files are NOT write-protected (for example, if the model files have been committed and made write-protected, the model can be opened!!!).
So, I tried to investigate more deeply launching Papyrus in debug mode, and I got the following message error (see below). After this error occurrence, no other model can be opened up to the restart of eclipse...
At this point I suspect that the problem may be related to a maximum size of the XML parser in the decoding phase and/or in the XML encoding when saving the model. Another possible issue is that the model tree is quite deep (up to 15 nested items)
What do you think?
Best Regards,
Nicola
-------------------------------------------------------------------------
!ENTRY org.eclipse.equinox.event 4 0 2015-12-10 17:38:58.522
!MESSAGE Exception while dispatching event org.osgi.service.event.Event [topic=org/eclipse/e4/ui/model/ui/ElementContainer/selectedElement/SET] {NewValue=org.eclipse.e4.ui.model.application.ui.basic.impl.PartImpl@142a721 (elementId: org.eclipse.e4.ui.compatibility.editor, tags: [Editor, org.eclipse.papyrus.infra.core.papyrusEditor, removeOnHide], contributorURI: null) (widget: ContributedPartRenderer$2 {}, renderer: org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer@16a73c, toBeRendered: true, onTop: false, visible: true, containerData: null, accessibilityPhrase: null) (contributionURI: bundleclass://org.eclipse.ui.workbench/org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor, object: null, context: PartImpl (org.eclipse.e4.ui.compatibility.editor) Context, variables: [], label: null, iconURI: null, tooltip: null, dirty: false, closeable: true, description: null), ChangedElement=org.eclipse.e4.ui.model.application.ui.basic.impl.PartStackImpl@1e11910 (elementId: org.eclipse.e4.primaryDataStack, tags: [org.eclipse.e4.primaryDataStack, EditorStack], contributorURI: null) (widget: CTabFolder {}, renderer: org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer@1cd1d3c, toBeRendered: true, onTop: false, visible: true, containerData: null, accessibilityPhrase: null), EventType=SET, AttName=selectedElement, Widget=CTabFolder {}} to handler org.eclipse.e4.ui.services.internal.events.UIEventHandler@5effa2
!STACK 0
java.lang.OutOfMemoryError: Java heap space
at com.sun.org.apache.xerces.internal.util.XMLStringBuffer.append(Unknown Source)
at com.sun.org.apache.xerces.internal.util.XMLStringBuffer.append(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLScanner.scanAttributeValue(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(Unknown Source)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:175)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:261)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1518)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1297)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:259)
at org.eclipse.papyrus.infra.core.resource.ModelSet.demandLoad(ModelSet.java:380)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:406)
at org.eclipse.papyrus.infra.core.resource.ModelSet.getResource(ModelSet.java:221)
at org.eclipse.papyrus.infra.core.resource.AbstractBaseModel.loadModel(AbstractBaseModel.java:184)
at org.eclipse.papyrus.infra.core.resource.ModelSet.loadModels(ModelSet.java:584)
at org.eclipse.papyrus.infra.core.editor.CoreMultiDiagramEditor.loadModelAndServices(CoreMultiDiagramEditor.java:616)
at org.eclipse.papyrus.infra.core.editor.CoreMultiDiagramEditor.initContents(CoreMultiDiagramEditor.java:921)
at org.eclipse.papyrus.infra.core.editor.CoreMultiDiagramEditor.init(CoreMultiDiagramEditor.java:489)
at org.eclipse.ui.internal.EditorReference.initialize(EditorReference.java:361)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:319)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
|
|
|
| Re: Limitations in the size of Papyrus models [message #1717301 is a reply to message #1717198] |
Fri, 11 December 2015 13:30 |
|
Hi, Nicola,
No, the out-of-memory condition is rarely traceable so directly to the
root cause. When the heap runs out, whatever code is the next to
request an allocation of memory, doing anything at all on any thread,
will have an OutOfMemoryError thrown at it by the JVM. The code that
runs into this error has nothing to do with the reasons why the heap
was exhausted.
And, yes, out-of-memory is a fatal condition that requires the JVM to
shut down. There is no possible recovery because any code anywhere can
just fail unexpectedly at any time.
Cheers,
Christian
On 2015-12-10 17:08:04 +0000, Nicola Mazzacane said:
> Hi,
>
> I have applied part of the suggested actions (increase memory
> resources, closing diagrams, etc.), but the result was not conclusive:
> after application of repeatable changes (in general, new model items
> and filling of text in some properties of stereotypes), the model
> cannot be no longer opened if the files are NOT write-protected (for
> example, if the model files have been committed and made
> write-protected, the model can be opened!!!).
>
> So, I tried to investigate more deeply launching Papyrus in debug mode,
> and I got the following message error (see below). After this error
> occurrence, no other model can be opened up to the restart of eclipse...
>
> At this point I suspect that the problem may be related to a maximum
> size of the XML parser in the decoding phase and/or in the XML encoding
> when saving the model. Another possible issue is that the model tree is
> quite deep (up to 15 nested items)
>
> What do you think?
>
> Best Regards,
> Nicola
>
> -------------------------------------------------------------------------
> !ENTRY org.eclipse.equinox.event 4 0 2015-12-10 17:38:58.522
> !MESSAGE Exception while dispatching event org.osgi.service.event.Event
> [topic=org/eclipse/e4/ui/model/ui/ElementContainer/selectedElement/SET]
> {NewValue=mailto:org.eclipse.e4.ui.model.application.ui.basic.impl.PartImpl@142a721
> (elementId: org.eclipse.e4.ui.compatibility.editor, tags: [Editor,
> org.eclipse.papyrus.infra.core.papyrusEditor, removeOnHide],
> contributorURI: null) (widget: ContributedPartRenderer$2 {}, renderer:
> mailto:org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer@16a73c,
> toBeRendered: true, onTop: false, visible: true, containerData: null,
> accessibilityPhrase: null) (contributionURI:
> bundleclass://org.eclipse.ui.workbench/org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor,
> object: null, context: PartImpl
> (org.eclipse.e4.ui.compatibility.editor) Context, variables: [], label:
> null, iconURI: null, tooltip: null, dirty: false, closeable: true,
> description: null),
> ChangedElement=mailto:org.eclipse.e4.ui.model.application.ui.basic.impl.PartStackImpl@1e11910
> (elementId: org.eclipse.e4.primaryDataStack, tags:
> [org.eclipse.e4.primaryDataStack, EditorStack], contributorURI: null)
> (widget: CTabFolder {}, renderer:
> mailto:org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer@1cd1d3c,
> toBeRendered: true, onTop: false, visible: true, containerData: null,
> accessibilityPhrase: null), EventType=SET, AttName=selectedElement,
> Widget=CTabFolder {}} to handler
> mailto:org.eclipse.e4.ui.services.internal.events.UIEventHandler@5effa2
> !STACK 0
> java.lang.OutOfMemoryError: Java heap space
> at
> com.sun.org.apache.xerces.internal.util.XMLStringBuffer.append(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.util.XMLStringBuffer.append(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLScanner.scanAttributeValue(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
> Source)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
> Source)
> at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(Unknown Source)
> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:175)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:261)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1518)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1297)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:259)
>
> at
> org.eclipse.papyrus.infra.core.resource.ModelSet.demandLoad(ModelSet.java:380)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:406)
>
> at
> org.eclipse.papyrus.infra.core.resource.ModelSet.getResource(ModelSet.java:221)
>
> at
> org.eclipse.papyrus.infra.core.resource.AbstractBaseModel.loadModel(AbstractBaseModel.java:184)
>
> at
> org.eclipse.papyrus.infra.core.resource.ModelSet.loadModels(ModelSet.java:584)
>
> at
> org.eclipse.papyrus.infra.core.editor.CoreMultiDiagramEditor.loadModelAndServices(CoreMultiDiagramEditor.java:616)
>
> at
> org.eclipse.papyrus.infra.core.editor.CoreMultiDiagramEditor.initContents(CoreMultiDiagramEditor.java:921)
>
> at
> org.eclipse.papyrus.infra.core.editor.CoreMultiDiagramEditor.init(CoreMultiDiagramEditor.java:489)
>
> at
> org.eclipse.ui.internal.EditorReference.initialize(EditorReference.java:361)
>
> at
> org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:319)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 01:17:52 GMT 2024
Powered by FUDForum. Page generated in 0.03149 seconds |
] 
Search
Help
Register
Login
Home
