| CacheAdapter Memory Leak [message #474874] |
Thu, 02 August 2007 20:53  |
 Steffen Becker
Messages: 31
Registered: July 2009 |
Member |
|
|
Dear UML2 Developers,
in the oAW component in the GMT projects we came across a problem and
currently don't know how to solve it. Maybe you can help...
We are loading an UML2 Profile into different ResourceSets several
times. After accessing the information of the Profile (for code
completion, for example) we abandon the ResourceSet in hope of the
garbage collector collecting it and freeing the memory again. Before we
stop using the Profile, we even unload it from the ResourceSet by
calling profileResource.unload(). However, the memory is not released.
In the memory profiler we see that the class CacheAdapter or
CacheAdapter$InverseCrossReferencer allocate the memory. (See Bug 197079
for the memory profiler's result).
I suspected the CacheAdapter to not unregister itself from the resource
when the resource gets unloads. Hence, I forced the removal of the
adapter by calling resource.eAdapters.clear(). This solved a part of the
problem, one test we have is working now. However, there is still a test
failing with OutOfMemory.
First question is, are we doing something wrong? Is the API expecting a
different call or call order? Is it a bug that the Adapter is not
removed when the resource gets unload?
Second question is: can you think of other locations in the code which
might hold a reference to the CacheAdapter preventing it from being
garbage collected? Any hints on what to search for?
Thanks in advance for any help.
Cheers,
Steffen
|
|
|
| Re: CacheAdapter Memory Leak [message #474986 is a reply to message #474874] |
Tue, 07 August 2007 18:35  |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
Hi Steffen,
Can you tell me what version of the UML2 API you are using.
Older versions of the API had memory leak issues. Can you try with the
latest 2.1 and let me know your results.
The CrossReferencer refers to objects within a resource so all that you
really need to do ( in theory ) is unload all your resources in the resource
set and the memory should be freed. Perhaps you are only unloading some of
the resources and the adapter has a reference to some item in a resource
that is not unloaded?
Calling resource.eAdapters.clear() should not be necessary but is an extra
level of security. You might also want to try that with the resource set
itself.
Exactly how much memory is leaking by the way? Is it a trivial amount (
ie. one reference ) or more?
- James.
"Steffen Becker" <becker@informatik.uni-oldenburg.de> wrote in message
news:f8tgd6$eua$1@build.eclipse.org...
> Dear UML2 Developers,
>
> in the oAW component in the GMT projects we came across a problem and
> currently don't know how to solve it. Maybe you can help...
>
> We are loading an UML2 Profile into different ResourceSets several
> times. After accessing the information of the Profile (for code
> completion, for example) we abandon the ResourceSet in hope of the
> garbage collector collecting it and freeing the memory again. Before we
> stop using the Profile, we even unload it from the ResourceSet by
> calling profileResource.unload(). However, the memory is not released.
> In the memory profiler we see that the class CacheAdapter or
> CacheAdapter$InverseCrossReferencer allocate the memory. (See Bug 197079
> for the memory profiler's result).
>
> I suspected the CacheAdapter to not unregister itself from the resource
> when the resource gets unloads. Hence, I forced the removal of the
> adapter by calling resource.eAdapters.clear(). This solved a part of the
> problem, one test we have is working now. However, there is still a test
> failing with OutOfMemory.
>
> First question is, are we doing something wrong? Is the API expecting a
> different call or call order? Is it a bug that the Adapter is not
> removed when the resource gets unload?
>
> Second question is: can you think of other locations in the code which
> might hold a reference to the CacheAdapter preventing it from being
> garbage collected? Any hints on what to search for?
>
> Thanks in advance for any help.
>
> Cheers,
> Steffen
|
|
|
| Re: CacheAdapter Memory Leak [message #624261 is a reply to message #474874] |
Tue, 07 August 2007 18:35 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
Hi Steffen,
Can you tell me what version of the UML2 API you are using.
Older versions of the API had memory leak issues. Can you try with the
latest 2.1 and let me know your results.
The CrossReferencer refers to objects within a resource so all that you
really need to do ( in theory ) is unload all your resources in the resource
set and the memory should be freed. Perhaps you are only unloading some of
the resources and the adapter has a reference to some item in a resource
that is not unloaded?
Calling resource.eAdapters.clear() should not be necessary but is an extra
level of security. You might also want to try that with the resource set
itself.
Exactly how much memory is leaking by the way? Is it a trivial amount (
ie. one reference ) or more?
- James.
"Steffen Becker" <becker@informatik.uni-oldenburg.de> wrote in message
news:f8tgd6$eua$1@build.eclipse.org...
> Dear UML2 Developers,
>
> in the oAW component in the GMT projects we came across a problem and
> currently don't know how to solve it. Maybe you can help...
>
> We are loading an UML2 Profile into different ResourceSets several
> times. After accessing the information of the Profile (for code
> completion, for example) we abandon the ResourceSet in hope of the
> garbage collector collecting it and freeing the memory again. Before we
> stop using the Profile, we even unload it from the ResourceSet by
> calling profileResource.unload(). However, the memory is not released.
> In the memory profiler we see that the class CacheAdapter or
> CacheAdapter$InverseCrossReferencer allocate the memory. (See Bug 197079
> for the memory profiler's result).
>
> I suspected the CacheAdapter to not unregister itself from the resource
> when the resource gets unloads. Hence, I forced the removal of the
> adapter by calling resource.eAdapters.clear(). This solved a part of the
> problem, one test we have is working now. However, there is still a test
> failing with OutOfMemory.
>
> First question is, are we doing something wrong? Is the API expecting a
> different call or call order? Is it a bug that the Adapter is not
> removed when the resource gets unload?
>
> Second question is: can you think of other locations in the code which
> might hold a reference to the CacheAdapter preventing it from being
> garbage collected? Any hints on what to search for?
>
> Thanks in advance for any help.
>
> Cheers,
> Steffen
|
|
|
Powered by
FUDForum. Page generated in 0.02795 seconds
] 
Search
Help
Register
Login
Home
