Community
Participate
Working Groups
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.
Created attachment 205578 [details] Proposed patch
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.
(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!
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.
