Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » Limitations in the size of Papyrus models
Limitations in the size of Papyrus models [message #1717053] Wed, 09 December 2015 18:02 Go to next message
Nicola Mazzacane is currently offline Nicola MazzacaneFriend
Messages: 21
Registered: September 2014
Junior Member
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 19:38 Go to previous messageGo to next message
Charles Rivet is currently offline Charles RivetFriend
Messages: 219
Registered: May 2014
Location: Canada
Senior Member

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 Go to previous messageGo to next message
Camille Letavernier is currently offline Camille LetavernierFriend
Messages: 926
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 Go to previous messageGo to next message
Nicola Mazzacane is currently offline Nicola MazzacaneFriend
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 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1206
Registered: July 2009
Location: Canada
Senior Member

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 13:41 Go to previous message
Nicola Mazzacane is currently offline Nicola MazzacaneFriend
Messages: 21
Registered: September 2014
Junior Member
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:
  


Current Time: Tue Jul 07 16:29:42 GMT 2020

Powered by FUDForum. Page generated in 0.02254 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top