Jose Alberto Fernandez wrote:

Given the realization of Peter, maybe we need to embark on
a code review of the tasks, at least the most important
to make sure we do not keep hold or objects unnecessarily.

If you look at the memory utitization numbers I submitted
all of them are like much larger, even before the first script
gets to be ran. I think it may have to do with this issue.

Jose Alberto

[EMAIL PROTECTED]:

Antonie, you are correct........
The script task object is referenced by the wrapper pointer
in RuntimeConfigurable, the RuntimeConfigurable object is referenced by
the UnknownElement, the UnknownElement is referenced by its parent and
it by the target and it by the project.

So tasks in ant are created and never GC'ed - not good.




I realized that tasks are never GCed because there was a bugzilla report about the <propertyfile/> task.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21505
Before I fixed the bug, the propertyfile task was storing the result of an operation say 3+1 into the slot of one of the operands, say 4.
If the same task was called a second time in an antcall, the user would then add 4 to 1 instead of 3 to 1.


Because of these type of issues, a number of tasks which in the execute method are changing instance variables are resetting these instance variables at the end of the execute method.

There are lots of constructs like :

public void execute() {

savedProperty1 = property1;
savedProperty2 = property2;

/* do something */

property1 = savedProperty1;
property2 = savedProperty2;

}

This does not look too nice and might not be entirely foolproof - in case of exceptions happening somewhere in the execution of the task for instance, and not allowing the instance variables to be resetted
to their values prior to execution.


Cheers,

Antoine


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to