You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by gl...@ca.ibm.com on 2000/07/18 15:18:20 UTC
[PATCH] Less memory consumption for subbuilds
This is an alternative to the patch I posted on the weekend for adding
inherited property support to a project. It acomplishes the goal of saving
memory by not copying all the parent build properties into the sub build
untill just before configuring it with ProjectHelper. Also, the execute
method now has a try/finally block to ensure the subproject p1 is set to
null so it can be GC'ed (thanks for pointing that out Conor).
Index: jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Ant.java
===================================================================
RCS file:
/home/cvspublic/jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Ant.java,v
retrieving revision 1.10
diff -u -r1.10 Ant.java
--- jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Ant.java
2000/07/12 06:36:11 1.10
+++ jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Ant.java
2000/07/18 13:09:51
@@ -114,43 +114,49 @@
p1.addTaskDefinition(taskName, taskClass);
}
- // set user-define properties
- Hashtable prop1 = project.getProperties();
- Enumeration e = prop1.keys();
- while (e.hasMoreElements()) {
- String arg = (String) e.nextElement();
- String value = (String) prop1.get(arg);
- p1.setProperty(arg, value);
- }
}
/**
* Do the execution.
*/
public void execute() throws BuildException {
- if( dir==null) dir=".";
-
- p1.setBasedir(dir);
- p1.setUserProperty("basedir" , dir);
-
- // Override with local-defined properties
- Enumeration e = properties.elements();
- while (e.hasMoreElements()) {
- Property p=(Property) e.nextElement();
- // System.out.println("Setting " + p.getName()+ " "
+ p.getValue());
- p.init();
- }
-
- if (antFile == null) antFile = dir + "/build.xml";
-
- p1.setUserProperty( "ant.file" , antFile );
- ProjectHelper.configureProject(p1, new File(antFile));
-
- if (target == null) {
- target = p1.getDefaultTarget();
+ try {
+ if( dir==null) dir=".";
+
+ p1.setBasedir(dir);
+ p1.setUserProperty("basedir" , dir);
+
+ // set user-define properties
+ Hashtable prop1 = project.getProperties();
+ Enumeration e = prop1.keys();
+ while (e.hasMoreElements()) {
+ String arg = (String) e.nextElement();
+ String value = (String) prop1.get(arg);
+ p1.setProperty(arg, value);
+ }
+
+ // Override with local-defined properties
+ e = properties.elements();
+ while (e.hasMoreElements()) {
+ Property p=(Property) e.nextElement();
+ // System.out.println("Setting " + p.getName()+
" " + p.getValue());
+ p.init();
+ }
+
+ if (antFile == null) antFile = dir + "/build.xml";
+
+ p1.setUserProperty( "ant.file" , antFile );
+ ProjectHelper.configureProject(p1, new File(antFile));
+
+ if (target == null) {
+ target = p1.getDefaultTarget();
+ }
+
+ p1.executeTarget(target);
+
+ } finally {
+ p1 = null;
}
-
- p1.executeTarget(target);
}
public void setDir(String d) {
Glenn McAllister
TID - Software Developer - VisualAge for Java
IBM Toronto Lab, (416) 448-3805
"An approximate answer to the right question is better than the
right answer to the wrong question." - John W. Tukey
Re: [PATCH] Less memory consumption for subbuilds
Posted by Stefan Bodewig <bo...@bost.de>.
actually we don't even need to call p1.init() at all - only
detectJavaVersion(). Loading default-taskdefs and copying System
properties is not necessary as we are going to transfer *all* taskdefs
and properties from the parent project anyway.
Stefan
Re: [PATCH] Less memory consumption for subbuilds
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "CM" == Conor MacNeill <co...@m64.com> writes:
>> From: Stefan Bodewig [mailto:bodewig@bost.de]
>> Can anybody see a reason why we shouldn't move the whole code from
>> init over to execute?
>>
CM> The only issue would be the createProperty method. Obviously p1
CM> must be instantiated.
Yes, of course, should have been clearer.
p1 could be instantiated in a constructor or directly at the
declaration point as well.
CM> I don't know if there will be any effect of setting the user
CM> properties first.
No. If it is set first, the "normal" setProperty call will be
ignored. If it's called afterwards, the value inside the "normal"
properties get replaced by the userProperty value.
CM> I'd also keep it as a separate method to be called from
CM> execute().
Fear execute is getting to long? Maybe we should split it differently
then.
Stefan
RE: [PATCH] Less memory consumption for subbuilds
Posted by Conor MacNeill <co...@m64.com>.
> From: Stefan Bodewig [mailto:bodewig@bost.de]
>
> I've just looked through this patch, Glenn has moved the part where
> the subproject's properties get set from init to execute.
>
> Can anybody see a reason why we shouldn't move the whole code from
> init over to execute?
>
Stefan,
The only issue would be the createProperty method. Obviously p1 must be
instantiated. I don't know if there will be any effect of setting the user
properties first. (I have to go and look at that code a little to know the
difference). I'd also keep it as a separate method to be called from
execute().
Conor
Re: [PATCH] Less memory consumption for subbuilds
Posted by Stefan Bodewig <bo...@bost.de>.
I've just looked through this patch, Glenn has moved the part where
the subproject's properties get set from init to execute.
Can anybody see a reason why we shouldn't move the whole code from
init over to execute?
Stefan
Re: [PATCH] Less memory consumption for subbuilds
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "gm" == glennm <gl...@ca.ibm.com> writes:
gm> Also, the execute method now has a try/finally block to ensure
gm> the subproject p1 is set to null so it can be GC'ed (thanks for
gm> pointing that out Conor).
This approach has a serious problem. It relies on the fact that a
particular instance of a task will be executed once and only once -
this might not be true.
If you've given an id to the task, this one can be referenced via
Project.getReferences() and nothing is stopping another task - be it a
script task or one written in Java - to invoke execute on it again.
What can we do about this?
(1) Check whether there is a reference to this instance (or the
surrounding target) and only null p1 if there isn't?
(2) Put a disclaimer into the docs saying "Ant tasks may only be
executed once"?
(3) Don't drop the reference to p1?
I'd prefer (1).
Stefan