Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Leaky injections
Leaky injections [message #1580752] Fri, 23 January 2015 17:48 Go to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi<br>
<br>
I've been trying to ensure that my Xtext contribution to the Sample
Ecore Editor does not provoke memory leaks by locking the editor in
memory as a consequence of stale references from global resources.<br>
<br>
For Ecore alone the Sample Ecore Editor seems well-behaved even
though EcoreEditor.dispose() relies on GC rather than unload to
clean up the ResourceSet.<br>
<br>
(There is perhaps a platform issue that you need to select something
outside the editor to clear the residual SelectionProvider reference
to the editor's contents.<br>
 Should closing an editor cancel any selection? Yes for seriously
complex objects. No for trivial text.)<br>
<br>
However once I have Xtext injection involved, more serious problems
arise, most obviously through the xxxJavaValidator's state, but even
when that is eliminated the problem just moves to another injected
state.<br>
<br>
The VisualVM trace to the nearest JNI root after:<br>
a) Open Sample Ecore Editor on a resource that uses Xtext support<br>
b) Invoking Validate<br>
c) Closing Editor<br>
d) Selecting some text in a text editor to release the selection
reference<br>
is:<br>
<br>
<img src="https://www.eclipse.org/forums/index.php?t=getfile&amp;id=20564" alt=""><br>
<br>
EcoreEditor$2 is an EContentAdapter that is attached to a variety of
model resources, so it locks many other things in memory.<br>
<br>
I'm not clear whether either the Initializer should null out its
creatingThread reference<br>
<br>
or<br>
<br>
the InheritingState should be set to some benign idle value.<br>
<br>
Has anyone looked at this? <br>
<br>
    Regards<br>
<br>
        Ed Willink<br>
<br>
<br>
</body>
</html>
  • Attachment: idcddffa.png
    (Size: 36.24KB, Downloaded 158 times)
Re: Leaky injections [message #1585876 is a reply to message #1580752] Mon, 26 January 2015 14:39 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3118
Registered: July 2009
Senior Member
Hi Ed,

did you meant to ask this on the Xtext newsgroup? I don't see how the
adapters for the editor are related to Xtext.

Best,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: Leaky injections [message #1586040 is a reply to message #1585876] Mon, 26 January 2015 16:33 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Yes in the absence of a Guice newsgroup.

The problem I see is that Guice injectors have a creatingThread
reference no doubt to assist in doing more work, but this reference
contributes to leakages.

Regards

Ed Willink


On 26/01/2015 14:39, Sebastian Zarnekow wrote:
> Hi Ed,
>
> did you meant to ask this on the Xtext newsgroup? I don't see how the
> adapters for the editor are related to Xtext.
>
> Best,
> Sebastian
Re: Leaky injections [message #1589157 is a reply to message #1580752] Wed, 28 January 2015 09:14 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3118
Registered: July 2009
Senior Member
Hi Ed,

where does the xxxJavaValidator leak some state? Could you please point
me into the right direction?

From looking at the code, it's not entirely clear to me why the
ValidateAction keeps a strong reference to the selection provider. Is it
used somewhere? At least in my target platfrom, I cannot find a
reference to it. Maybe that's a trace worthy to follow. Doesn't look
like a DI or Xtext issue, though.

Best,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: Leaky injections [message #1589251 is a reply to message #1589157] Wed, 28 January 2015 10:22 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

I agree that
org.eclipse.emf.edit.ui.action.ValidateAction.selectionProvider is
write-only and so not used. Unfortunately it is protected and so has
been API ever since written 10 years ago. (The variable was write-only
in the first commit too). No Bugzilla seems to request it. But the
Sample Ecore Editor when editing Ecore files does not have this leak
problem, so I see no point in raising an EMF Bugzilla against
ValidateAction.selectionProvider that cannot even be considered until
EMF 3.0.

It is the extra complexity of injection that provokes the leakage since,
the e.g. InheritingState's infrastructure seems to reference via an
Initializer.creatingThread and a Runnable to the ValidateAction.

I found a State associated with the xxxJavaValidator that was a closer
JNI root, but I wasn't using the xxxJavaValidator, so I eliminated it
and moved on to the more distant JNI root in the screen shot.

My current thinking is that either the State is referencing more than it
should, or the State is not being shut down properly. The magic of
injection is indeed all magic to me, hence my query hoping for help from
someone who knows better.

(I tried a simpler repro, using injection and none of my code, by
opening a *.xtext with the Sample Reflective Ecore Editor. This used to
work and so allow a user to save the underlying model, but now Bug 458620.)

The shut down in EcoreEditor is certainly poor since the Resources are
not unloaded. To get OCL code to shutdown at all I had to register an
additional AdapterFactory so that there is an EcoreEditor.dispose call-back.

Bottom line. OCL Xtext-based code has an Injector-related leakage in the
Ecore Editor. Is it an OCL/Xtext/Injection/EcoreEditor bug? Maybe there
is some simple additional action that the EcoreEditor.dispose call-back
needs to do to break the injector references.

Regards

Ed Willink



On 28/01/2015 09:14, Sebastian Zarnekow wrote:
> Hi Ed,
>
> where does the xxxJavaValidator leak some state? Could you please
> point me into the right direction?
>
> From looking at the code, it's not entirely clear to me why the
> ValidateAction keeps a strong reference to the selection provider. Is
> it used somewhere? At least in my target platfrom, I cannot find a
> reference to it. Maybe that's a trace worthy to follow. Doesn't look
> like a DI or Xtext issue, though.
>
> Best,
> Sebastian
Re: Leaky injections [message #1589284 is a reply to message #1589251] Wed, 28 January 2015 10:46 Go to previous message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3118
Registered: July 2009
Senior Member
Hi Ed,

I expect the reference from the injector to the created instance is due
to the fact that the instance is marked as a singleton in that injector.
The question is: why does a singleton reference some instance and
doesn't release it, e.g. what is ValidateAction$1 and how is it created.
Maybe that's a trace to follow?

Regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Previous Topic:syntax difference problem
Next Topic:Unresolved cross references with cyclic project references
Goto Forum:
  


Current Time: Fri Apr 19 10:06:44 GMT 2024

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

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

Back to the top