Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » MoDisco » Issues with Modicso 0.9
Issues with Modicso 0.9 [message #685977] Tue, 21 June 2011 08:33 Go to next message
Dmitry Smirnov is currently offline Dmitry SmirnovFriend
Messages: 92
Registered: July 2009
Member
Hi,

I'm trying to create a model from the existing Java code and I see 2 issues:

1. If I try to discover a Java model from Java project, the model is created but I was unable to save it. Option serialize is true, there is a file in filesystem, but its length is 0. And if model is opened in editor, I cannot save it (there is no such an option).

BTW, is there is a way to convert Java model to UML?

2. If I try to discover a KDM code model from the same Java project, I see the following exception: An invalid XML character (Unicode: 0x2) was found in the element content:"" (see stack below)

Is this a known problem? Is there any remedy?

java.lang.RuntimeException: An invalid XML character (Unicode: 0x2) was found in the element content:""
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl$Escape.convert(XMLSaveImpl.java:3325)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.getDatatypeValue(XMLSaveImpl.java:3109)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveDataTypeSingle(XMLSaveImpl.java:1694)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1276)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedSingle(XMLSaveImpl.java:2399)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1543)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedSingle(XMLSaveImpl.java:2399)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1543)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2413)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1549)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedSingle(XMLSaveImpl.java:2399)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1543)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2413)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1549)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2413)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1549)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2413)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1549)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2413)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1549)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2413)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1549)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2413)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1549)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2413)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1549)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1177)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1038)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2413)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1549)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1220)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2712)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:683)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:591)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:257)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:333)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:1423)
at org.eclipse.modisco.util.atl.core.internal.AtlLaunchHelper.initModels(AtlLaunchHelper.java:146)
at org.eclipse.modisco.util.atl.core.internal.AtlLaunchHelper.runTransformation(AtlLaunchHelper.java:187)
at org.eclipse.modisco.util.atl.core.internal.AtlLaunchHelper.runTransformation(AtlLaunchHelper.java:173)
at org.eclipse.modisco.util.atl.core.internal.AtlLaunchHelper.runTransformation(AtlLaunchHelper.java:220)
at org.eclipse.modisco.java.discoverer.internal.TranslateJavaModelToKdm.getKDMModelFromJavaModelWithCustomTransformation(TranslateJavaModelToKdm.java:87)
at org.eclipse.modisco.java.discoverer.internal.TranslateJavaModelToKdm.getKDMModelFromJavaModelWithCustomTransformation(TranslateJavaModelToKdm.java:65)
at org.eclipse.modisco.java.discoverer.DiscoverKDMModelFromJavaProject.discoverKDM(DiscoverKDMModelFromJavaProject.java:62)
at org.eclipse.modisco.java.discoverer.DiscoverKDMModelFromProject.basicDiscoverElement(DiscoverKDMModelFromProject.java:55)
at org.eclipse.modisco.java.discoverer.DiscoverKDMModelFromProject.basicDiscoverElement(DiscoverKDMModelFromProject.java:1)
at org.eclipse.modisco.infra.discovery.core.AbstractDiscoverer.discoverElement(AbstractDiscoverer.java:93)
at org.eclipse.modisco.infra.discovery.core.AbstractModelDiscoverer.discoverElement(AbstractModelDiscoverer.java:183)
at org.eclipse.modisco.infra.discovery.ui.internal.actions.MoDiscoMenuSelectionListener.discovererElement(MoDiscoMenuSelectionListener.java:352)
at org.eclipse.modisco.infra.discovery.ui.internal.actions.MoDiscoMenuSelectionListener$1.run(MoDiscoMenuSelectionListener.java:115)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Re: Issues with Modicso 0.9 [message #686456 is a reply to message #685977] Wed, 22 June 2011 09:16 Go to previous messageGo to next message
Fabien Giquel is currently offline Fabien GiquelFriend
Messages: 147
Registered: July 2009
Senior Member
Hi Dmitry,

such problems have not been identified yet. Is it possible for you to register one bugzilla entry, with (it is important) a test case (for instance where to find the java project you tried to analyse) ?

Once you have obtained one .kdm model file from java code, you can use on it the discoverer "discover UML model from KDM model..." (http://wiki.eclipse.org/MoDisco/Components/KDM/Documentation/0.9#KDM_to_UML_Converter)

Fabien.


----------------------------------------------------
Fabien GIQUEL
R&D Engineer
Mia-Software
rue Nina Simone
44000 NANTES
----------------------------------------------------
Re: Issues with Modicso 0.9 [message #687767 is a reply to message #686456] Thu, 23 June 2011 07:39 Go to previous messageGo to next message
Dmitry Smirnov is currently offline Dmitry SmirnovFriend
Messages: 92
Registered: July 2009
Member
I'm affraid I cannot provide a test case immediately: the code I'm working with is a propriatary code. It is derived from Android platform.

I had tried to test case #1 (cleate Java model) with oure Android Gingerbread and it works good: file is saved correcly.

Perhaps, both problems relate to the same issue (non Unicode symbol).

I would try to investigate the problem by myself, but do not have any idea except getting all the code, building it and debugging.
If you know better way (like turning some additional logging), please let me know.

Dmitry
Re: Issues with Modicso 0.9 [message #689371 is a reply to message #687767] Mon, 27 June 2011 14:23 Go to previous messageGo to next message
Dmitry Smirnov is currently offline Dmitry SmirnovFriend
Messages: 92
Registered: July 2009
Member
I've found a reason for the exception:
one of the source files contains the following expression:

return "x"+ some_var +"x";


where x is the symbol of 0x2 hex code. (Java Editor shows it as a small empty rectangle)

Note that the Java compiler does not report it as a problem. Exception happens on "Saving discovered model" stage.

Not sure what to do next: is this can be treated as a Modisco problem?

Well, if I exclude the problematic file from the Java project, discovering still unsuccessfull: it terminated with Out-of-memory error. I'm using 512 MB configured in eclipse ini.
There are about 350 Java files in the project.
Does it requires so much memory or this might be some kind of memory leak?

Dmitry
Re: Issues with Modicso 0.9 [message #690235 is a reply to message #689371] Wed, 29 June 2011 08:41 Go to previous messageGo to next message
Fabien Giquel is currently offline Fabien GiquelFriend
Messages: 147
Registered: July 2009
Senior Member
Hi Dmitry,

you may enter a bugzilla in MDT.MoDisco project in attaching the Java class (or subpart) which contains the problematic symbols.


MoDisco Java discoverer should reasonably work with some 300 Java classes, if classes have some "usual" size (sloc). It has been tested on some projects with more than 300000 lines of code (you may have a look at execution time benchmark "http://wiki.eclipse.org/MoDisco/Components/Java/Documentation/0.9#Benchmark_results").
But may be if your classes have a quite long number of lines, or if you have checked the analysis of one jar dependency, it may be required to increase your Xmx argument in eclipse ini to more than 512 Mb.


----------------------------------------------------
Fabien GIQUEL
R&D Engineer
Mia-Software
rue Nina Simone
44000 NANTES
----------------------------------------------------
Re: Issues with Modicso 0.9 [message #690797 is a reply to message #690235] Thu, 30 June 2011 08:45 Go to previous messageGo to next message
Dmitry Smirnov is currently offline Dmitry SmirnovFriend
Messages: 92
Registered: July 2009
Member
I had already created https://bugs.eclipse.org/bugs/show_bug.cgi?id=350529

As for the Out-of-memory, I had tried to analyse the problem with the MAT.
According to this analysis, the biggest objects are:

Label | Number Of Objects | Used Heap Size | Retained Heap Size | Retained Heap, %
org.eclipse.core.internal.jobs.Worker | 6 | 720 | 271 119 624 | 73,94%
org.eclipse.core.internal.dtree.DeltaDataTree | 3 | 72 | 51 946 896 | 14,17%
org.eclipse.jdt.internal.core.JavaModelManager | 1 | 192 | 10 601 768 | 2,89%

the most consuming objects of Worker are

Class Name | Shallow Heap | Retained Heap | Percentage
org.eclipse.emf.ecore.xmi.impl.StringSegment$Element[9316] @ 0x1bf3f588 | 37 280 | 148 581 576 | 40,52%
byte[75898880] @ 0x1dd832f0 <?xml version="1.0"... | 75 898 896 | 75 898 896 | 20,70%
org.eclipse.gmt.modisco.java.emf.impl.ModelImpl @ 0x12364670 | 48 | 25 044 176 | 6,83%

It looks like 'byte' contains the whole xmi file which is being written by MoDisco. Is it a good behaviour? In my project I just added one package to build path and did not include all the packages that are referenced by this one. I'm wondering what amount of heap I should provide to Java to discover whole Android project (BTW, the same test with Android Gingerbread Telephony Framework behaves differently: Modisco seems enters some endless loop.)

Dmitry
Re: Issues with Modicso 0.9 [message #690872 is a reply to message #690797] Thu, 30 June 2011 11:00 Go to previous messageGo to next message
Dmitry Smirnov is currently offline Dmitry SmirnovFriend
Messages: 92
Registered: July 2009
Member
I've figured out that OOM happened when Java model is serialized before transformation to KDM (see stack below)

Worker-9
at java.lang.OutOfMemoryError.<init>()V (Unknown Source)
at java.util.Arrays.copyOf([BI)[B (Unknown Source)
at java.io.ByteArrayOutputStream.write([BII)V (Unknown Source)
at org.eclipse.emf.ecore.xmi.impl.StringSegment.writeAscii(Ljava/io/OutputStream;I)V (StringSegment.java:333)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeAscii(Ljava/io/OutputStream;)V (XMLSaveImpl.java:1018)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(Lorg/eclipse/emf/ecore/xmi/XMLResource;Ljava/io/OutputStream;Ljava/util/Map;)V (XMLSaveImpl.java:261)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(Ljava/io/OutputStream;Ljava/util/Map;)V (XMLResourceImpl.java:333)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(Ljava/io/OutputStream;Ljava/util/Map;)V (ResourceImpl.java:1423)
at org.eclipse.modisco.util.atl.core.internal.AtlLaunchHelper.initModels(Ljava/util/Map;Ljava/util/List;Ljava/util/List;)V (AtlLaunchHelper.java:146)
at org.eclipse.modisco.util.atl.core.internal.AtlLaunchHelper.runTransformation(Ljava/net/URL;Ljava/util/List;Ljava/util/List;Ljava/util/List;)Ljava/util/List; (AtlLaunchHelper.java:187)
at org.eclipse.modisco.util.atl.core.internal.AtlLaunchHelper.runTransformation(Ljava/net/URL;Ljava/util/List;Ljava/util/List;)Ljava/util/List; (AtlLaunchHelper.java:173)
at org.eclipse.modisco.util.atl.core.internal.AtlLaunchHelper.runTransformation(Ljava/net/URL;Lorg/eclipse/modisco/util/atl/core/internal/AtlLaunchHelper$ModelInfo;Lorg/eclipse/modisco/util/atl/core/internal/AtlLaunchHelper$ModelInfo;)Lorg/eclipse/emf/ecore/resource/Resource; (AtlLaunchHelper.java:220)
at org.eclipse.modisco.java.discoverer.internal.TranslateJavaModelToKdm.getKDMModelFromJavaModelWithCustomTransformation(Lorg/eclipse/emf/common/util/URI;Lorg/eclipse/emf/ecore/resource/Resource;Ljava/net/URL;Lorg/eclipse/emf/common/util/URI;)Lorg/eclipse/emf/ecore/resource/Resource; (TranslateJavaModelToKdm.java:87)
at org.eclipse.modisco.java.discoverer.internal.TranslateJavaModelToKdm.getKDMModelFromJavaModelWithCustomTransformation(Lorg/eclipse/emf/common/util/URI;Lorg/eclipse/emf/ecore/resource/Resource;Lorg/eclipse/emf/common/util/URI;)Lorg/eclipse/emf/ecore/resource/Resource; (TranslateJavaModelToKdm.java:65)
at org.eclipse.modisco.java.discoverer.DiscoverKDMModelFromJavaProject.discoverKDM(Lorg/eclipse/jdt/core/IJavaProject;Lorg/eclipse/emf/common/util/URI;Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/emf/ecore/resource/Resource; (DiscoverKDMModelFromJavaProject.java:62)
at org.eclipse.modisco.java.discoverer.DiscoverKDMModelFromJavaProject.basicDiscoverElement(Lorg/eclipse/jdt/core/IJavaProject;Lorg/eclipse/core/runtime/IProgressMonitor;)V (DiscoverKDMModelFromJavaProject.java:46)
at org.eclipse.modisco.java.discoverer.DiscoverKDMModelFromJavaProject.basicDiscoverElement(Ljava/lang/Object;Lorg/eclipse/core/runtime/IProgressMonitor;)V (DiscoverKDMModelFromJavaProject.java:1)
at org.eclipse.modisco.infra.discovery.core.AbstractDiscoverer.discoverElement(Ljava/lang/Object;Lorg/eclipse/core/runtime/IProgressMonitor;)V (AbstractDiscoverer.java:93)
at org.eclipse.modisco.infra.discovery.core.AbstractModelDiscoverer.discoverElement(Ljava/lang/Object;Lorg/eclipse/core/runtime/IProgressMonitor;)V (AbstractModelDiscoverer.java:183)
at org.eclipse.modisco.infra.discovery.ui.internal.actions.MoDiscoMenuSelectionListener.discovererElement(Ljava/lang/Object;Ljava/util/Map;Lorg/eclipse/modisco/infra/discovery/core/IDiscoverer;Lorg/eclipse/core/runtime/IProgressMonitor;)V (MoDiscoMenuSelectionListener.java:352)
at org.eclipse.modisco.infra.discovery.ui.internal.actions.MoDiscoMenuSelectionListener$1.run(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus; (MoDiscoMenuSelectionListener.java:115)
at org.eclipse.core.internal.jobs.Worker.run()V (Worker.java:54)
Re: Issues with Modicso 0.9 [message #691495 is a reply to message #690872] Fri, 01 July 2011 15:11 Go to previous messageGo to next message
Gregoire Dupe is currently offline Gregoire DupeFriend
Messages: 75
Registered: September 2009
Location: France
Member
Hello,

It may be a problem in org.eclipse.modisco.util.atl.core.internal.AtlLaunchHelper.initModels. We will check that next week.

Until we answer to this question, you may try to increase the value of the Xmx of your JVM.

Regards,
Grégoire

Re: Issues with Modicso 0.9 [message #693328 is a reply to message #685977] Wed, 06 July 2011 09:20 Go to previous messageGo to next message
Dmitry Smirnov is currently offline Dmitry SmirnovFriend
Messages: 92
Registered: July 2009
Member
I had increased the pool. This had allowed me to pass this out-of-memory, but still have an issue: the process of discovery seems to be entering endless loop.

I had tried to debug the discovery and it does not seems to hung up: the stack (see below) of the process is varying: I can go up by stack to some level (like ASMOperation.realExec(ASMStackFrame) line: 251). then it goes down again with different parameters (I do not have sources of ATL, so cannot debug it fully).

But discovering is not ending. I was waiting for few hours. While it is running, machine is very irresponsive - CPU is occupied by eclipse.

Unfortunately, I do not know how to discover what is the progress (i.e. how many items are converted, how much are remaining). Is it possible that discovering is enetered some endless loop?


Thread [Worker-11] (Suspended)
Class<T>.isPrimitive() line: not available [native method]
EClassImpl(EClassifierImpl).isInstance(Object) line: 182
ASMEMFModel.addElementsOfType(Set, EClassifier, Resource) line: 267
ASMEMFModel.getElementsByType(ASMModelElement) line: 217
ASMEMFModelElement.allInstancesFrom(StackFrame, ASMEMFModelElement, ASMString) line: 764
ASMEMFModelElement.allInstances(StackFrame, ASMEMFModelElement) line: 706
GeneratedMethodAccessor38.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not available
Method.invoke(Object, Object...) line: not available
ClassNativeOperation.exec(StackFrame) line: 69
ASMEMFModelElement(ASMOclAny).invoke(StackFrame, Operation, List) line: 130
ASMEMFModelElement.invoke(StackFrame, String, List) line: 926
ASMOperation.realExec(ASMStackFrame) line: 251
ASMOperation.exec(StackFrame) line: 173
ASMModule(ASMOclAny).invoke(StackFrame, Operation, List) line: 130
ASMModule(ASMOclAny).invoke(StackFrame, String, List) line: 78
ASMOperation.realExec(ASMStackFrame) line: 251
ASMOperation.realExec(ASMStackFrame) line: 357
ASMOperation.exec(StackFrame) line: 173
ASMModule(ASMOclAny).invoke(StackFrame, Operation, List) line: 130
ASMModule(ASMOclAny).invoke(StackFrame, String, List) line: 78
ASMOperation.realExec(ASMStackFrame) line: 251
ASMOperation.exec(StackFrame) line: 173
ASMInterpreter.<init>(ASM, ASMModule, ASMExecEnv, Map) line: 346
AtlLauncher.launch(ASM, Map, Map, Map, List, Map, Debugger) line: 216
AtlLauncher.launch(URL, Map, Map, Map, List, Map, Debugger) line: 127
AtlLauncher.launch(URL, Map, Map, Map, List, Map) line: 92
AtlLaunchHelper.runTransformation(URL, List<ModelInfo>, List<ModelInfo>, List<URL>) line: 194
AtlLaunchHelper.runTransformation(URL, List<ModelInfo>, List<ModelInfo>) line: 173
AtlLaunchHelper.runTransformation(URL, AtlLaunchHelper$ModelInfo, AtlLaunchHelper$ModelInfo) line: 220
TranslateJavaModelToKdm.getKDMModelFromJavaModelWithCustomTransformation(URI, Resource, URL, URI) line: 87
TranslateJavaModelToKdm.getKDMModelFromJavaModelWithCustomTransformation(URI, Resource, URI) line: 65
DiscoverKDMModelFromJavaProject.discoverKDM(IJavaProject, URI, IProgressMonitor) line: 62
DiscoverKDMModelFromJavaProject.basicDiscoverElement(IJavaProject, IProgressMonitor) line: 46
DiscoverKDMModelFromJavaProject.basicDiscoverElement(Object, IProgressMonitor) line: 1
DiscoverKDMModelFromJavaProject(AbstractDiscoverer<T>).discoverElement(T, IProgressMonitor) line: 93
DiscoverKDMModelFromJavaProject(AbstractModelDiscoverer<T>).discoverElement(T, IProgressMonitor) line: 183
MoDiscoMenuSelectionListener.discovererElement(Object, Map<DiscovererParameter,Object>, IDiscoverer<?>, IProgressMonitor) line: 352
MoDiscoMenuSelectionListener$1.run(IProgressMonitor) line: 115
Worker.run() line: 54
Re: Issues with Modicso 0.9 [message #699757 is a reply to message #693328] Fri, 22 July 2011 09:10 Go to previous messageGo to next message
Nicolas Bros is currently offline Nicolas BrosFriend
Messages: 49
Registered: July 2009
Member
Hi Dmitry,

First, sorry for the long response time.

We have created a benchmark for the KDM discoverer, and it shows that the discovery time is indeed very long : on the 3GHz CPU we tested it on, it takes an average of 20 minutes per mebibyte (see attached benchmark results). Most of this time is spent in the ATL transformation.

I have created a patch that should speed up the transformation by using the new ATL VM (Bug 351531). I will now run the benchmark again with this patch to compare the results.
  • Attachment: benchmark.zip
    (Size: 176.83KB, Downloaded 444 times)
Re: Issues with Modisco 0.9 [message #701590 is a reply to message #699757] Mon, 25 July 2011 09:32 Go to previous message
Fabien Giquel is currently offline Fabien GiquelFriend
Messages: 147
Registered: July 2009
Senior Member
Hi Dmitry,

Nicolas last benchmark (see last message) produced the same performance results as the precedent one.
We need more time to investigate on the Java->kdm transformation rules to understand where the problem is (registered into bugzilla : https://bugs.eclipse.org/bugs/show_bug.cgi?id=352985).

Thank you for your understanding.

Fabien.


----------------------------------------------------
Fabien GIQUEL
R&D Engineer
Mia-Software
rue Nina Simone
44000 NANTES
----------------------------------------------------
Previous Topic:Query Manager
Next Topic:how to make AND operation between two conditions in EmfFacet
Goto Forum:
  


Current Time: Tue Apr 23 11:43:58 GMT 2024

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

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

Back to the top