Community
Participate
Working Groups
Build Identifier: M20110210-1200 Currently, RegistryReader.EPackageDescriptor.getEPackage() is not synchronized, which means concurrent threads calling this method increase the risk of classloader-related deadlock due to but 212262 and of EPackage.eInstance initialization-related race conditions across threads. Reproducible: Sometimes Steps to Reproduce: 1. Use the Eclipse Modeling Tooks package; install MoDisco, QVTo and UML 2. Open views that, at Eclipse startup, will trigger concurrent queries to RegistryReader.EPackageDescriptor.getEPackage() - QVTo's Metamodel Browser view - MoDisco's EPackage Registry 3. Open editor windows that, at Eclipse startup, will trigger similar concurrent queries. This is particularly easy with QVTo Editor windows as each window has a separate QVTo editor thread that, upon startup, will query the EMF EPackage registry for the metamodels used in the QVTo file associated with that editor window. To do this, create simple QVTo library files and open them in separate QVTo editor windows: ----A.qvto--- modeltype UML uses 'http://www.eclipse.org/uml2/3.0.0/UML'; library A; ---- ---B.qvto---- modeltype EMF uses 'http://www.eclipse.org/emf/2002/Ecore'; library B; ------------ 4. Now, we have several views/windows with associated threads that, upon initialization, will concurrently ping the EMF EPackage registry... 5. Quit Eclipse. 6. Restart Eclipse. During initialization when Eclipse restores the views & windows, there will be lots of concurrent calls to RegistryReader.EPackageDescriptor.getEPackage() This can lead to nasty deadlocks where Eclipse is completely frozen. The real cause of the deadlock occurs when 2 or more threads concurrently force the classloader to load / initialize the same EPackage. This can happen well after initialization but initialization is the most reliable way I found to trigger this bug. EMF's EPackage registry is implicated in related classloader deadlock problems I've reported before: https://bugs.eclipse.org/bugs/show_bug.cgi?id=277621 https://bugs.eclipse.org/bugs/show_bug.cgi?id=287102
Created attachment 191227 [details] Proposed patch for synchronizing RegistryReader.EPackageDescriptor.getEPackage() This patch works well for me when Eclipse is configured per Thomas Watson's suggestion here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=331818#c3 The unsynchronized EMF EPackage API exacerbates Eclipse's vulnerability to https://bugs.eclipse.org/bugs/show_bug.cgi?id=212262 For modeling-intensive uses of Eclipse, I strongly suggest fixing this bug ASAP.
Nicolas, I don't believe there's anything in EMF we should do based on what you've described. It seems clear to me that adding synchronization will increase the possibility of deadlock, so that's contributing to a problem not to a solution and I'm not comfortable with that. In https://bugs.eclipse.org/bugs/show_bug.cgi?id=277621 I see no evidence of EMF package registry being involved. Even with with https://bugs.eclipse.org/bugs/show_bug.cgi?id=287102 there's nothing to imply that EMF itself is holding any locks or that multiple threads are trying to load two packages at the same time, i.e., I only see one XyzPackageImpl on the stacks. In neither case is getEPackage on the stack, so what's the basis of your assertion that adding synchronize here will prevent deadlock? If you want me to consider this issue further, please provide a trace with deadlocks involving getPackage(). My expectation is that Classloaders should never ever deadlock, because other wise you could never ever write safe Java code.
I think it is irrelevant, if EMF's package initialization might cause deadlocks in multi threaded environments or not, because the EMF framework does NOT give any guarantees about thread safety (except the EMF Transaction API). So in my point of view, it is simply not correct to access the (singleton) package registry from multiple threads without proper synchronization. Or in other words: As EMF does not claim to be thread safe, you can't blame it for not being it. (By the way: Maybe some centric EMF classes SHOULD be thread safe, but that's another point...)
This specific stuff (package initialization and access to generated static Ecore metadata) is generally designed to be thread safe. The only problem I'm aware of is mutually dependent packages where each different thread starts initializing a different package first. I don't think this case deadlocks though. I'm not aware of this initialization code ever causing a deadlock and I'd hate for it to start doing that!
Initializing different packages on different threads should be OK as far as EMF is concerned; however, this initialization behavior typically requires loading package-specific classes. When T1 initializes package P1 and T2 initializes package P2, T1 and T2 will induce a lot of concurrent java classloading. If P1 and P2 have shared dependencies on unitialized packages, then we have a situation that can induce a java classloader related deadlock situation like that described in 212262.
It's not clear to me how adding additional locks helps prevent deadlocks rather than providing a new cause for them...
It is hard to believe, but we've run into exactly the same problem today! Both, our RCP client as well as our JBoss EJB server, suffer from deadlocks caused by concurrent ecore package initialization. We're using three independent eclipse jobs to fetch model objects from our server. We could solve the problem on the server by pre-loading/initializing all ecore packages at server startup (using one single thread of course). The problem on the client still exists - I'm going to experiment with a synchronized package registry implementation and report the results here.
This are the results of our first experiments with a thread safe EPackage.Registry: The client side deadlock could be prevented. It was caused by parallel invocations of getEPackage(uri) of three jobs that concurrently loaded resources. In cases like that, additional locks can in fact avoid deadlocks: If just one thread can enter package initialization code at all, there can of course be no deadlock! BUT: As soon as different threads cause package initialization by directly accessing constants of the package interface (e.g. MyPackage.Literals... or MyPackage.eINSTANCE), thread synchronization on package registry level is "too late" and in fact causes additional deadlocks: (1) Thread T1 locks MyPackage due to class initialization (L1). (2) Thread T2 locks My2ndPackage due to class initialization (L2). (3) Thread T1 wants to load dependent My2ndPackage via registry.getEPackage(uri). As initialization of My2ndPackage is still in progress, T1 has to wait for T2 to unlock L2. (4) Tread T2 wants to load dependent MyPackage via registry.getEPackage(uri). As the registry is thread safe, T2 cannot access it as T1 already holds lock L1 on it. Result: Deadlock, as T1 holds L1 and waits for L2 which is held by T2. In that case, Ed is right: Additional locks do not prevent a deadlock...
Mario's report confirms what I've experienced with multiple QVTO Editor windows that, when restored at Eclipse startup, trigger concurrent calls to registry.getEPackage(uri) based on the metamodels referenced in each QVTO file. To avoid this, I have synchornized the EMF EPackage API calls and, as Mario also confirmed, that's not enough. I also synchornized the operations of the QVTO Compiler that was responsible for the concurrent calls to registry.getEPackage(uri) It would be unreasonable to synchronize every EMF-based application; however, it seems to me equally unreasonable to expect any kind of robustness from registry.getEPackage(uri) since it can recursively invoke itself and call classloader operations. The combination of these two things makes extablishing strong progress conditions necessary for avoiding deadlock practically impossible to achieve without strong guarantees from the EPackages we're loading and what their initialization behavior can do. One approach might be to create a separate EMF EPackage resolver thread responsible for loading and initializing all requested EPackages using the caller's classloader context. We might be able to relax this with EMF's proxies so that the call to registry.getEPackage(uri) would return with a proxy if the package isn't loaded and the resolution of the proxy would block until the EMF Epackage resolver thread got around to loading the requested package. This seems to me a non-trivial thing to do; on the other hand, I believe that eventually it will be clearer and important to decouple the loading of EPackages from EMF-based applications and serialize their loading to avoid race conditions with the java classloader and logical race conditions with EPackages' initialization behavior.
I tried a version of Helios SR2 EMF where I turned off global synchronization on the EMF EPackage registry. I can induce EMF/classloader race conditions that result in a deadlock when Eclipse starts. Eclipse is refreshing 2 views: - the Metamodel browser view (which shows all of the EMF EPackages in the registry) - a QVTO editor page These two views induce lazy class loading of various EPackage implementations. Both threads were in the midst of querying the EMF EPackage registry when the classloader deadlock happened. {code} Daemon Thread [Thread-1] (Suspended) Unsafe.ensureClassInitialized(Class) line: not available [native method] UnsafeFieldAccessorFactory.newFieldAccessor(Field, boolean) line: 25 ReflectionFactory.newFieldAccessor(Field, boolean) line: 122 Field.acquireFieldAccessor(boolean) line: 918 Field.getFieldAccessor(Object) line: 899 Field.get(Object) line: 358 RegistryReader$EPackageDescriptor.getEPackage() line: 277 EPackageImpl$1.getEPackage() line: 168 EPackageRegistryImpl.getEPackage(String) line: 133 UtilitiesPackageImpl.init() line: 165 UtilitiesPackage.<clinit>() line: 83 Unsafe.ensureClassInitialized(Class) line: not available [native method] UnsafeFieldAccessorFactory.newFieldAccessor(Field, boolean) line: 25 ReflectionFactory.newFieldAccessor(Field, boolean) line: 122 Field.acquireFieldAccessor(boolean) line: 918 Field.getFieldAccessor(Object) line: 899 Field.get(Object) line: 358 RegistryReader$EPackageDescriptor.getEPackage() line: 277 EPackageRegistryImpl.getEPackage(String) line: 133 TypesPackageImpl.init() line: 212 TypesPackage.<clinit>() line: 83 EcorePackageImpl.init() line: 521 EcorePackage.<clinit>() line: 86 ImperativeOCLPackageImpl.init() line: 341 ImperativeOCLPackage.<clinit>() line: 78 ExpressionsPackageImpl.init() line: 329 ExpressionsPackage.<clinit>() line: 78 Unsafe.ensureClassInitialized(Class) line: not available [native method] UnsafeFieldAccessorFactory.newFieldAccessor(Field, boolean) line: 25 ReflectionFactory.newFieldAccessor(Field, boolean) line: 122 Field.acquireFieldAccessor(boolean) line: 918 Field.getFieldAccessor(Object) line: 899 Field.get(Object) line: 358 RegistryReader$EPackageDescriptor.getEPackage() line: 277 EmfMetamodelDesc.getModel() line: 61 MetamodelBrowserView$3(MetamodelBrowser).doCreateInput() line: 502 MetamodelBrowser$5.run() line: 473 BusyIndicator.showWhile(Display, Runnable) line: 70 MetamodelBrowserView$3(MetamodelBrowser).createInput() line: 471 MetamodelBrowserView$3(MetamodelBrowser).<init>(Composite, int) line: 168 MetamodelBrowserView$3(MetamodelBrowser).<init>(Composite) line: 145 MetamodelBrowserView$3.<init>(MetamodelBrowserView, Composite) line: 111 MetamodelBrowserView.createPartControl(Composite) line: 111 ViewReference.createPartHelper() line: 375 ViewReference.createPart() line: 229 ViewReference(WorkbenchPartReference).getPart(boolean) line: 595 ViewPane(PartPane).setVisible(boolean) line: 313 ViewPane.setVisible(boolean) line: 529 PresentablePart.setVisible(boolean) line: 180 PresentablePartFolder.select(IPresentablePart) line: 270 LeftToRightTabOrder.select(IPresentablePart) line: 65 TabbedStackPresentation.selectPart(IPresentablePart) line: 473 ViewStack(PartStack).refreshPresentationSelection() line: 1254 ViewStack(PartStack).createControl(Composite, StackPresentation) line: 666 ViewStack(PartStack).createControl(Composite) line: 574 ViewSashContainer(PartSashContainer).createControl(Composite) line: 568 PerspectiveHelper.activate(Composite) line: 272 Perspective.onActivate() line: 981 WorkbenchPage.onActivate() line: 2632 WorkbenchWindow$27.run() line: 2992 BusyIndicator.showWhile(Display, Runnable) line: 70 WorkbenchWindow.setActivePage(IWorkbenchPage) line: 2973 WorkbenchWindow$21.runWithException() line: 2290 WorkbenchWindow$21(StartupThreading$StartupRunnable).run() line: 31 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 134 Display.runAsyncMessages(boolean) line: 3593 Display.readAndDispatch() line: 3286 IDEWorkbenchAdvisor(WorkbenchAdvisor).openWindows() line: 803 Workbench$31.runWithException() line: 1567 Workbench$31(StartupThreading$StartupRunnable).run() line: 31 UISynchronizer(Synchronizer).syncExec(Runnable) line: 179 UISynchronizer.syncExec(Runnable) line: 150 Display.syncExec(Runnable) line: 4240 StartupThreading.runWithoutExceptions(StartupThreading$StartupRunnable) line: 94 Workbench.init() line: 1562 Workbench.runUI() line: 2567 Workbench.access$4(Workbench) line: 2438 Workbench$7.run() line: 671 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 664 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 115 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 369 EclipseStarter.run(String[], Runnable) line: 179 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 Main.invokeFramework(String[], URL[]) line: 620 Main.basicRun(String[]) line: 575 Main.run(String[]) line: 1408 Main.main(String[]) line: 1384 {code} and: {code} Daemon Thread [org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconciler] (Suspended) Unsafe.ensureClassInitialized(Class) line: not available [native method] UnsafeFieldAccessorFactory.newFieldAccessor(Field, boolean) line: 25 ReflectionFactory.newFieldAccessor(Field, boolean) line: 122 Field.acquireFieldAccessor(boolean) line: 918 Field.getFieldAccessor(Object) line: 899 Field.get(Object) line: 358 RegistryReader$EPackageDescriptor.getEPackage() line: 277 EPackageRegistryImpl.getEPackage(String) line: 133 ExpressionsPackageImpl.init() line: 418 ExpressionsPackage.<clinit>() line: 85 EcoreEnvironment.<clinit>() line: 91 QvtOperationalStdLibrary.<init>(QvtCompilerOptions) line: 101 QvtOperationalStdLibrary.createLibrary(QvtCompilerOptions) line: 366 QvtOperationalStdLibrary.<clinit>() line: 68 ExeXMIResource.<init>(URI) line: 321 ExeXMIResource$Factory.createResource(URI) line: 53 CompiledUnit$1(ResourceSetImpl).createResource(URI, String) line: 425 CompiledUnit$1(ResourceSetImpl).demandCreateResource(URI) line: 239 CompiledUnit$1(ResourceSetImpl).getResource(URI, boolean) line: 391 QVTOCompiler.getCompiledExeXMIUnit(QvtOperationalEnvFactory, QvtCompilerOptions, UnitProxy) line: 619 QVTOCompiler.loadCompiled(QvtOperationalEnvFactory, UnitProxy, IProgressMonitor) line: 261 QvtCompilerFacade.compile(ITextEditor, IDocument, QvtOperationalEnvFactory, IProgressMonitor) line: 75 QvtReconcilingStrategy$1.execute(IProgressMonitor) line: 89 QvtReconcilingStrategy.reconcileInternal() line: 92 QvtReconcilingStrategy.initialReconcile() line: 72 QvtReconciler(MonoReconciler).initialProcess() line: 105 AbstractReconciler$BackgroundThread.run() line: 173 {code} Is there a mechanism available to force a high-priority initialization of the EMF EPackage registry in a non-lazy manner? Alternatively, is there a way to force Eclipse *not* to restore any view/page for which there is directly or indirectly a dependency on populating the EMF EPackage registry? In practice, it's really annoying to remember to close all such views before quittting Eclipse. - Nicolas.
Certainly anyone can iterate over the EPackage.Registry.INSTANCE and force all packages to be initialized early. This would force activation of all model bundles and would defeat much of Eclipse's lazy loading behavior. It seems like overkill. If this is issue is caused by QVT kicking off a background thread, it might be appropriate for QVT itself ensure that the models it knows will be needed have all been initialized before kicking off a work thread. It seems a simple approach...
Created attachment 202367 [details] Patch for QVTO's emf.util plugin to force early initialization of *all* registered EPackages. Ed, Is this the forced initialization you are talking about? Normally, this plugin will be initialized before all other plugins that directly or indirectly depend on it. Does the actual order of initialization for the qvto.emf.util plugin matter w.r.t. to other plugins that directly or indirectly depend on EMF but are completely unrelated to QVTO? For example, if we had a plugin A that doesn't depend on QVTO but registers a bunch of metamodels. If qvto.emf.util is initialized before A, will the EMF extensions registered in A nonetheless force A to be initialized when the qvto.emf.util plugin scans the package registry? I suppose that such behavior might not be kosher in some cases but then it's really the simplest solution to a nasty problem.
The patch you show is the brute force method I suggested. I think that would be atrocious behavior though, especially in an environment where a sizable number of the bundles contain EMF models, which is increasingly the case... Far better would be for QVT to consider which packages it directly and indirectly depends on and to use this idiom for each. <Xyz>Package.eINSTANCE.eClass() Likely it's even as simple as just doing ExpressionsPackage.eINSTANCE.eClass() in the bundle start where currently you're effectively doing this for all packages in the entire IDE. After all, I can see in both threads that ExpressionsPackage.<clinit>() line: 85 is on the stack so single threading that specific initialization should eliminate this specific possibility for deadlock. Are you able to test that theory?
The problem is that when lazy EPackage initialization kicks in, it can be very catastrophic. I have another session where Eclipse got stuck. There is a global lock on the QVTO compiler to throttle down how much concurrent accesses to the EPackage registry QVTO induces What do you suggest for the following set of threads? {code} 2011-08-29 14:53:48 Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.1-b02-384 mixed mode): "Worker-23" prio=5 tid=11464f000 nid=0x122661000 waiting for monitor entry [12265f000] java.lang.Thread.State: BLOCKED (on object monitor) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.doCompile(QVTOCompiler.java:457) - waiting to lock <7f54426c0> (a java.lang.Class for org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.compileSingleFile(QVTOCompiler.java:419) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.compile(QVTOCompiler.java:204) at org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder.rebuildAll(QVTOBuilder.java:242) at org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder.fullBuild(QVTOBuilder.java:125) at org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder.access$0(QVTOBuilder.java:124) at org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder$1.execute(QVTOBuilder.java:101) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118) - locked <7d1b73aa8> (a org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder$1) at org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder.build(QVTOBuilder.java:106) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343) at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:344) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:825) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:702) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:924) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1128) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Locked ownable synchronizers: - None "org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconciler" daemon prio=1 tid=11f9db800 nid=0x1241af000 waiting for monitor entry [1241ae000] java.lang.Thread.State: BLOCKED (on object monitor) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.parse(QVTOCompiler.java:301) - waiting to lock <7f54426c0> (a java.lang.Class for org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.loadParsed(QVTOCompiler.java:275) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtCompilerFacade.compile(QvtCompilerFacade.java:80) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy$1.execute(QvtReconcilingStrategy.java:89) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy.reconcileInternal(QvtReconcilingStrategy.java:92) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy.initialReconcile(QvtReconcilingStrategy.java:72) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:105) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:173) Locked ownable synchronizers: - None "org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconciler" daemon prio=1 tid=145562000 nid=0x123aaf000 waiting for monitor entry [123aae000] java.lang.Thread.State: BLOCKED (on object monitor) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.parse(QVTOCompiler.java:301) - waiting to lock <7f54426c0> (a java.lang.Class for org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.loadParsed(QVTOCompiler.java:275) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtCompilerFacade.compile(QvtCompilerFacade.java:80) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy$1.execute(QvtReconcilingStrategy.java:89) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy.reconcileInternal(QvtReconcilingStrategy.java:92) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy.initialReconcile(QvtReconcilingStrategy.java:72) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:105) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:173) Locked ownable synchronizers: - None "org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconciler" daemon prio=1 tid=1206e1000 nid=0x123804000 waiting for monitor entry [123803000] java.lang.Thread.State: BLOCKED (on object monitor) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.parse(QVTOCompiler.java:301) - waiting to lock <7f54426c0> (a java.lang.Class for org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.loadParsed(QVTOCompiler.java:275) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtCompilerFacade.compile(QvtCompilerFacade.java:80) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy$1.execute(QvtReconcilingStrategy.java:89) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy.reconcileInternal(QvtReconcilingStrategy.java:92) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy.initialReconcile(QvtReconcilingStrategy.java:72) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:105) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:173) Locked ownable synchronizers: - None "org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconciler" daemon prio=1 tid=11fda3000 nid=0x122e5c000 in Object.wait() [122e5a000] java.lang.Thread.State: RUNNABLE at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.activities.mdfundamentalactivities.impl.MdfundamentalactivitiesPackageImpl.init(MdfundamentalactivitiesPackageImpl.java:253) at com.nomagic.uml2.ext.magicdraw.activities.mdfundamentalactivities.metadata.MdfundamentalactivitiesPackage.<clinit>(MdfundamentalactivitiesPackage.java:64) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.m2m.internal.qvt.oml.emf.util.mmregistry.EmfMetamodelDesc.getModel(EmfMetamodelDesc.java:61) at org.eclipse.m2m.internal.qvt.oml.emf.util.mmregistry.EmfMetamodelDesc.getLoadStatus(EmfMetamodelDesc.java:81) at org.eclipse.m2m.internal.qvt.oml.emf.util.mmregistry.MetamodelRegistry.toEPackageRegistry(MetamodelRegistry.java:87) at org.eclipse.m2m.internal.qvt.oml.compiler.CompilerUtils.getEPackageRegistry(CompilerUtils.java:121) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.getEPackageRegistry(QVTOCompiler.java:681) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.parse(QVTOCompiler.java:307) - locked <7f54426c0> (a java.lang.Class for org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.loadParsed(QVTOCompiler.java:275) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtCompilerFacade.compile(QvtCompilerFacade.java:80) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy$1.execute(QvtReconcilingStrategy.java:89) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy.reconcileInternal(QvtReconcilingStrategy.java:92) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy.initialReconcile(QvtReconcilingStrategy.java:72) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:105) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:173) Locked ownable synchronizers: - None "org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconciler" daemon prio=1 tid=1146cf000 nid=0x121b8c000 in Object.wait() [121b7e000] java.lang.Thread.State: RUNNABLE at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageImpl$1.getEPackage(EPackageImpl.java:168) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.actions.mdintermediateactions.impl.MdintermediateactionsPackageImpl.init(MdintermediateactionsPackageImpl.java:461) at com.nomagic.uml2.ext.magicdraw.actions.mdintermediateactions.metadata.MdintermediateactionsPackage.<clinit>(MdintermediateactionsPackage.java:64) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.actions.mdcompleteactions.impl.MdcompleteactionsPackageImpl.init(MdcompleteactionsPackageImpl.java:394) at com.nomagic.uml2.ext.magicdraw.actions.mdcompleteactions.metadata.MdcompleteactionsPackage.<clinit>(MdcompleteactionsPackage.java:66) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.actions.mdbasicactions.impl.MdbasicactionsPackageImpl.init(MdbasicactionsPackageImpl.java:366) at com.nomagic.uml2.ext.magicdraw.actions.mdbasicactions.metadata.MdbasicactionsPackage.<clinit>(MdbasicactionsPackage.java:64) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.actions.mdstructuredactions.impl.MdstructuredactionsPackageImpl.init(MdstructuredactionsPackageImpl.java:340) at com.nomagic.uml2.ext.magicdraw.actions.mdstructuredactions.metadata.MdstructuredactionsPackage.<clinit>(MdstructuredactionsPackage.java:62) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.compositestructures.mdinternalstructures.impl.MdinternalstructuresPackageImpl.init(MdinternalstructuresPackageImpl.java:305) at com.nomagic.uml2.ext.magicdraw.compositestructures.mdinternalstructures.metadata.MdinternalstructuresPackage.<clinit>(MdinternalstructuresPackage.java:62) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.compositestructures.mdports.impl.MdportsPackageImpl.init(MdportsPackageImpl.java:286) at com.nomagic.uml2.ext.magicdraw.compositestructures.mdports.metadata.MdportsPackage.<clinit>(MdportsPackage.java:64) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.compositestructures.mdcollaborations.impl.MdcollaborationsPackageImpl.init(MdcollaborationsPackageImpl.java:283) at com.nomagic.uml2.ext.magicdraw.compositestructures.mdcollaborations.metadata.MdcollaborationsPackage.<clinit>(MdcollaborationsPackage.java:63) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.mdusecases.impl.MdusecasesPackageImpl.init(MdusecasesPackageImpl.java:303) at com.nomagic.uml2.ext.magicdraw.mdusecases.metadata.MdusecasesPackage.<clinit>(MdusecasesPackage.java:63) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.mdprofiles.impl.MdprofilesPackageImpl.init(MdprofilesPackageImpl.java:309) at com.nomagic.uml2.ext.magicdraw.mdprofiles.metadata.MdprofilesPackage.<clinit>(MdprofilesPackage.java:62) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.auxiliaryconstructs.mdtemplates.impl.MdtemplatesPackageImpl.init(MdtemplatesPackageImpl.java:265) at com.nomagic.uml2.ext.magicdraw.auxiliaryconstructs.mdtemplates.metadata.MdtemplatesPackage.<clinit>(MdtemplatesPackage.java:62) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.auxiliaryconstructs.mdinformationflows.impl.MdinformationflowsPackageImpl.init(MdinformationflowsPackageImpl.java:271) at com.nomagic.uml2.ext.magicdraw.auxiliaryconstructs.mdinformationflows.metadata.MdinformationflowsPackage.<clinit>(MdinformationflowsPackage.java:61) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.auxiliaryconstructs.mdmodels.impl.MdmodelsPackageImpl.init(MdmodelsPackageImpl.java:260) at com.nomagic.uml2.ext.magicdraw.auxiliaryconstructs.mdmodels.metadata.MdmodelsPackage.<clinit>(MdmodelsPackage.java:61) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.mdprimitivetypes.impl.MdprimitivetypesPackageImpl.init(MdprimitivetypesPackageImpl.java:277) at com.nomagic.uml2.ext.magicdraw.mdprimitivetypes.metadata.MdprimitivetypesPackage.<clinit>(MdprimitivetypesPackage.java:58) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.classes.mdassociationclasses.impl.MdassociationclassesPackageImpl.init(MdassociationclassesPackageImpl.java:254) at com.nomagic.uml2.ext.magicdraw.classes.mdassociationclasses.metadata.MdassociationclassesPackage.<clinit>(MdassociationclassesPackage.java:60) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.classes.mdinterfaces.impl.MdinterfacesPackageImpl.init(MdinterfacesPackageImpl.java:257) at com.nomagic.uml2.ext.magicdraw.classes.mdinterfaces.metadata.MdinterfacesPackage.<clinit>(MdinterfacesPackage.java:63) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.classes.mdpowertypes.impl.MdpowertypesPackageImpl.init(MdpowertypesPackageImpl.java:247) at com.nomagic.uml2.ext.magicdraw.classes.mdpowertypes.metadata.MdpowertypesPackage.<clinit>(MdpowertypesPackage.java:62) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.classes.mddependencies.impl.MddependenciesPackageImpl.init(MddependenciesPackageImpl.java:275) at com.nomagic.uml2.ext.magicdraw.classes.mddependencies.metadata.MddependenciesPackage.<clinit>(MddependenciesPackage.java:61) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.deployments.mdcomponentdeployments.impl.MdcomponentdeploymentsPackageImpl.init(MdcomponentdeploymentsPackageImpl.java:242) at com.nomagic.uml2.ext.magicdraw.deployments.mdcomponentdeployments.metadata.MdcomponentdeploymentsPackage.<clinit>(MdcomponentdeploymentsPackage.java:62) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.deployments.mdartifacts.impl.MdartifactsPackageImpl.init(MdartifactsPackageImpl.java:246) at com.nomagic.uml2.ext.magicdraw.deployments.mdartifacts.metadata.MdartifactsPackage.<clinit>(MdartifactsPackage.java:64) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.deployments.mdnodes.impl.MdnodesPackageImpl.init(MdnodesPackageImpl.java:283) at com.nomagic.uml2.ext.magicdraw.deployments.mdnodes.metadata.MdnodesPackage.<clinit>(MdnodesPackage.java:63) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at com.nomagic.uml2.ext.magicdraw.classes.mdkernel.impl.MdkernelPackageImpl.init(MdkernelPackageImpl.java:620) at com.nomagic.uml2.ext.magicdraw.classes.mdkernel.metadata.MdkernelPackage.<clinit>(MdkernelPackage.java:68) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.delegatedGetEPackage(EPackageRegistryImpl.java:196) at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:149) at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.delegatedGetResource(ResourceSetImpl.java:337) at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:379) at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:216) at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:202) at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:262) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1483) at org.eclipse.emf.ecore.impl.ETypedElementImpl.getEType(ETypedElementImpl.java:321) at org.eclipse.emf.ecore.impl.ETypedElementImpl.eGet(ETypedElementImpl.java:557) at org.eclipse.ocl.ecore.impl.VariableImpl.eGet(VariableImpl.java:442) at org.eclipse.m2m.internal.qvt.oml.expressions.impl.VarParameterImpl.eGet(VarParameterImpl.java:298) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013) at org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImpl.hasNext(EContentsEList.java:409) at org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences(EcoreUtil.java:307) at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:287) at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:274) at org.eclipse.m2m.internal.qvt.oml.compiler.CompiledUnit.<init>(CompiledUnit.java:155) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.getCompiledExeXMIUnit(QVTOCompiler.java:619) at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.loadCompiled(QVTOCompiler.java:261) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtCompilerFacade.compile(QvtCompilerFacade.java:75) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy$1.execute(QvtReconcilingStrategy.java:89) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy.reconcileInternal(QvtReconcilingStrategy.java:92) at org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconcilingStrategy.initialReconcile(QvtReconcilingStrategy.java:72) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:105) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:173) Locked ownable synchronizers: - None "main" prio=6 tid=113801000 nid=0x7fff70aedca0 runnable [7fff5fbfc000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) at org.eclipse.swt.widgets.Widget._drawThemeProgressArea(Widget.java:695) at org.eclipse.swt.widgets.ProgressBar._drawThemeProgressArea(ProgressBar.java:139) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4967) at org.eclipse.swt.internal.cocoa.OS.objc_msgSend_bool(Native Method) at org.eclipse.swt.internal.cocoa.NSRunLoop.runMode(NSRunLoop.java:42) at org.eclipse.swt.widgets.Display.sleep(Display.java:4200) at org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(WorkbenchAdvisor.java:364) at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.eventLoopIdle(IDEWorkbenchAdvisor.java:887) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2641) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575) at org.eclipse.equinox.launcher.Main.run(Main.java:1408) Locked ownable synchronizers: - None "VM Thread" prio=9 tid=113872000 nid=0x11b4d1000 runnable "Gang worker#0 (Parallel GC Threads)" prio=9 tid=113802800 nid=0x113604000 runnable "Gang worker#1 (Parallel GC Threads)" prio=9 tid=113803000 nid=0x113707000 runnable "Concurrent Mark-Sweep GC Thread" prio=9 tid=11384d800 nid=0x11b1dd000 runnable "VM Periodic Task Thread" prio=10 tid=114057800 nid=0x11bce9000 waiting on condition "Exception Catcher Thread" prio=10 tid=113801800 nid=0x113501000 runnable JNI global references: 4370 {code}
So what's happening here? The QVT Compiler/Reconciler is kicking off a bunch of threads that are all doing compilation in parallel? All the threads that say BLOCKED are QVT threads. The ones doing package initialization say they're RUNNABLE; are they deadlocked nevertheless? Are all these threads sharing a resource set? Does anyone who knows what QVT is doing here on the CC list? Do so many threads need to be doing related activities all at once? I.e., can QvtReconcilingStrategy.initialReconcile be set up to avoid it being active on multiple threads at the same time?
(In reply to comment #15) > So what's happening here? This is activity is typical of the transient Eclipse startup phase where multiple threads are busy restoring the state of Eclipse views. > The QVT Compiler/Reconciler is kicking off a bunch > of threads that are all doing compilation in parallel? When a user opens a *.qvto file, there is a new thread for the QVTO Editor UI associated with that *.qvto file. So, if had A.qvto, B.qvto, C.qvto open when I quit Eclipse, at startup, there will be 3 QVTO Editor UI threads restoring the state of the view for A.qvto, B.qvto and C.qvto. Each QVTO Editor UI thread handles asynchronously a bunch of UI-related functionality like outlining, hover and reconciliation between the results of compiling the *.qvto source with the annotations/problems associated with that editor buffer, outline view and markers. > All the threads that > say BLOCKED are QVT threads. See below. > The ones doing package initialization say they're > RUNNABLE; are they deadlocked nevertheless? The RUNNABLE threads are in fact deadlocked in the Java classloader: {code} "org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconciler" daemon prio=1 tid=1146cf000 nid=0x121b8c000 in Object.wait() [121b7e000] java.lang.Thread.State: RUNNABLE at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) {code} and: {code} "org.eclipse.m2m.internal.qvt.oml.editor.ui.QvtReconciler" daemon prio=1 tid=11fda3000 nid=0x122e5c000 in Object.wait() [122e5a000] java.lang.Thread.State: RUNNABLE at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) at java.lang.reflect.Field.getFieldAccessor(Field.java:899) at java.lang.reflect.Field.get(Field.java:358) at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) {code} This is the pattern of EMF/Java classloader deadlock. Here we have 2 concurrent threads calling EPackage.Registry.getEPackage(). Neither package is present in the registry so EMF asks the Java classloader to load the registered EPackage implementations. This java classloading is happening concurrently on separate threads. The deadlock happens when there is a dependency from one EPackage to the other; there could be circular dependencies too. The point here is that concurrent lazy-loading of dependent EMF EPackages across multiple threads further exacerbates the vulneraibilities present in Java's classloading mechanism w.r.t race conditions. > Are all these threads sharing a > resource set? No. Each QVTO Editor has its own QVTO Compiler and therefore its own ResourceSet. > Does anyone who knows what QVT is doing here on the CC list? As I mentioned, this is typical behavior for restoring the state of an Eclipse UI editor view. THe thread responsible for restoring that editor state is involved in various initialization activities. In QVTO's case, the reconciler needs to be initialized. > Do so many threads need to be doing related activities all at once? I had multiple *.qvto editor windows open. Currently, each *.qvto editor window has its own thread. > I.e., can > QvtReconcilingStrategy.initialReconcile be set up to avoid it being active on > multiple threads at the same time? Having a single thread handle multiple *.qvto editor windows could help a little but that does not address the fundamental problem. The problem here is that there is no way to predict when we can have 2 or more threads that concurrently query the EMF EPackage registry and these queries lead to concurrent Java classloading. The problem begins when there are direct or indirect dependencies among the loaded packages. THis is the situation that leads to the threads to deadlock if the JVM can't handle concurrent, reentrant calls to the classloader as is the case obviously for the Apple JVM 1.6. In our case at JPL, we use QVTO extensively both in terms of development with the Eclipse QVTO UI stuff and in terms of execution by embedding the QVTO runtime in other tools. For this special case, I've added a global synchronization around the QVTO compiler to force all concurrent QVTO threads to use the QVTO compiler in a sequential fashion. I obviously missed adding synchronization wrappers for the QvtReconcilingStrategy. Without the wrappers, instead of 2 threads, there could have been 5 or 6 threads concurrently accessing the EMF EPackage registry and potentially more stuck somewhere in the bowels of the Java classloader. - Nicolas.
(In reply to comment #13) > The patch you show is the brute force method I suggested. I think that would > be atrocious behavior though, especially in an environment where a sizable > number of the bundles contain EMF models, which is increasingly the case... > > Far better would be for QVT to consider which packages it directly and > indirectly depends on and to use this idiom for each. > > <Xyz>Package.eINSTANCE.eClass() > > Likely it's even as simple as just doing > > ExpressionsPackage.eINSTANCE.eClass() > > in the bundle start where currently you're effectively doing this for all > packages in the entire IDE. After all, I can see in both threads that > > ExpressionsPackage.<clinit>() line: 85 > > is on the stack so single threading that specific initialization should > eliminate this specific possibility for deadlock. Are you able to test that > theory? I've implemented your suggestion; I'll get a better sense how robust this is in a few days. We see how it goes. Briefly, I've overloaded the EclipsePlugin.start(BundleContext) method for 2 QVTO plugins: org.eclipse.m2m.qvt.oml - forced loading of Expressions, CST & Trace packages org.eclipse.m2m.qvt.oml.ecore.impterativeocl - forced loading of ImperativeOCL package - Nicolas.
Thanks Ed! Your suggestion has been working just fine for several months now with EMF 2.6 maintenance (unmodified) + our custom Eclipse QVTO enhancements. This has been robust over thousands of Eclispe sessions & QVTO compilations/executions. This is of course not representative of general purpose EMF use but it strongly suggests that avoiding EMF EPackage/classloader related race conditions requires careful attention how the EMF registries (EPackage, converters, etc..) are initializaed/populated. - Nicolas. (In reply to comment #17) > (In reply to comment #13) ... > I've implemented your suggestion; I'll get a better sense how robust this is > in a few days. We see how it goes. > > Briefly, I've overloaded the EclipsePlugin.start(BundleContext) method for 2 > QVTO plugins: > org.eclipse.m2m.qvt.oml - forced loading of Expressions, CST & Trace packages > org.eclipse.m2m.qvt.oml.ecore.impterativeocl - forced loading of ImperativeOCL > package > > - Nicolas.
Will the latest Class Loader API modifications (since JDK 7) have (positive) impacts un this problem? http://openjdk.java.net/groups/core-libs/ClassLoaderProposal.html http://download.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html It seems these improvements exactly adresses this issue.
