Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 361452

Summary:

Memory leaks in tracing.ext when using with UML profiles

Product:

[Modeling] M2T

Reporter:

Tatiana Fesenko <tatiana.fesenko>

Component:

Xpand

Assignee:

Karsten Thoms <karsten.thoms>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

karsten.thoms

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Bug Depends on:

310361

Bug Blocks:

Attachments:

Description	Flags
A sample project demonstrating this issue. MemoryUsageTest invokes the same template many times and prints amout of used memory.	none
Proposed patch	none

Description Tatiana Fesenko

2011-10-19 14:33:41 EDT

Created attachment 205556 [details]
A sample project demonstrating this issue. MemoryUsageTest invokes the same template many times and prints amout of used memory.

Create a transformation that applies UML stereotype and uses traces for the stereotyped elements. 
"java.lang.OutOfMemoryError: Java heap space" will occur after some 100 iterations (after the fix for the bug 361382). 

I am using Eclipse Indigo with Xpand 1.1.1. We invoke the transformation from a servlet, thus, several threads can access TraceComponent and its static field traceStore concurrently. That's why we can't use clearTrace() as it can erase traces created and used by a concurrent thread. Also, it'd be good to make the methods from TraceComponent methods synchronized to allow to use them in a servlet.

The traces keep strong references to the traced elements so they won't be freed by GC. 

Using WeakReferences should help. My suggestion is to allow the user to choose among createTrace and createWeakTrace.

Comment 1 Tatiana Fesenko

2011-10-20 02:20:18 EDT

Created attachment 205578 [details]
Proposed patch

Comment 2 Karsten Thoms

2011-10-20 03:24:45 EDT

I think this would be just a workaround for the problem. Having weak references is not good for traces, since traces may get lost during GC.

We have to find another solution. The basic problem is that the TraceComponent uses this static TraceStore. The TraceStore must be local to the execution context. This could be achieved by moving the called trace methods to a new class TraceExtensions with non-static methods and deriving from AbstractStatefulExtensions, like in CounterExtensions.

The next problem is that the TraceStore might want to get shared into the WorkflowContext, since the TraceComponent might want to dump the trace to a file.

I'll have to think about a more general solution.

Comment 3 Tatiana Fesenko

2011-10-20 04:11:32 EDT

(In reply to comment #2)
> I think this would be just a workaround for the problem. Having weak references
> is not good for traces, since traces may get lost during GC.
My assumption was that since the model containing the source/target of the link is loaded there should be a strong reference to the traced elements. 

> We have to find another solution. The basic problem is that the TraceComponent
> uses this static TraceStore. The TraceStore must be local to the execution
> context. This could be achieved by moving the called trace methods to a new
> class TraceExtensions with non-static methods and deriving from
> AbstractStatefulExtensions, like in CounterExtensions.

I didn't think of this possibility. This solution is more generic and safer. 
 
> The next problem is that the TraceStore might want to get shared into the
> WorkflowContext, since the TraceComponent might want to dump the trace to a
> file.
> 
> I'll have to think about a more general solution.

Thanks!

Comment 4 Karsten Thoms

2020-04-30 13:55:01 EDT

This is a batch close of open M2T Xpand bugs. It is not planned work on this component in the foreseeable future. If you think this issue needs to be solved and you plan to contribute a fix then feel free to reopen it.