Eclipse Community Forums: Papyrus » Limitations in the size of Papyrus models

Home » Modeling » Papyrus » Limitations in the size of Papyrus models

Limitations in the size of Papyrus models [message #1717053]

Wed, 09 December 2015 13:02

Eclipse User

Hi,

we are managing a large model (about 6Mbyte) and after an impotant change we are no longer able to open it. With the previous version of the model, we noticed that the eclipse of heap reachesca. 750 Mbyte. The problem persists even with version 1.1.3 of Papyrus.

1) Is there a known maximum size in terms of number of the model items and/or size of the files for a correct usage of Papyrus? In such a case, a partitioning of the model (with the mechanism of the sub-models) could help?

2) Are there configurations of eclipse (eclipse.ini) that can help the manage of memory? Currently I have the following parameters:

--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
--launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion = 1.7
-Xms256m
-Xmx1024m

Any suggestions?

Thank you,
Nicola

Re: Limitations in the size of Papyrus models [message #1717072 is a reply to message #1717053]

Wed, 09 December 2015 14:38

Eclipse User

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.

Re: Limitations in the size of Papyrus models [message #1717144 is a reply to message #1717072]

Thu, 10 December 2015 04:26

Eclipse User

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

[Updated on: Thu, 10 December 2015 04:26] by Moderator

Re: Limitations in the size of Papyrus models [message #1717198 is a reply to message #1717144]

Thu, 10 December 2015 12:08

Eclipse User

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 08:30

Eclipse User

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)

FIXED: Limitations in the size of Papyrus models [message #1718415 is a reply to message #1717301]

Wed, 23 December 2015 08:41

Eclipse User

Hi Christian,

we have solved the problem, which actually was related to a maximum size of the XML parser.

The model has been populated automatically parsing a Word document. When extracting one string, I introduced in a text field of a stereotype the following 20 special characters (in hex):

90 b7 f0 f0 9d 9d 9d 91 91 8e f0 f0 9d a1 e2 88 99 91 8e

After saving the model, the text field of a stereotype in the file * .uml becomed unusually long, because the above character sequence is repeated several times, creating a string of more 143000 characters.

Best regards,
Nicola

Previous Topic:	OCL Constraints Context
Next Topic:	Context OCL Constraints

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 22:03:35 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter