ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: AW: ant really slow, 100% CPU?
Date Fri, 21 Sep 2007 09:27:35 GMT
Peter Reilly wrote:
> On 9/21/07, Steve Loughran <stevel@apache.org> wrote:
>> Peter Reilly wrote:
>>> 1) Some of the traces seem to imply a bug.
>>
>> clearly :)
>>
>>> org.apache.tools.ant.taskdefs.Property$PropertyResolver.evaluate(Property.java:110)
>>>         at
>>> org.apache.tools.ant.PropertyHelper.getProperty(PropertyHelper.java:787)
>>>         - locked <0x00002aaab4013548> (a
>>> org.apache.tools.ant.PropertyHelper)
>>>         at
>>> org.apache.tools.ant.PropertyHelper.parseNextProperty(PropertyHelper.java:541)
>>>         at
>>> org.apache.tools.ant.PropertyHelper.parseProperties(PropertyHelper.java:502)
>>>         at
>>> org.apache.tools.ant.RuntimeConfigurable.maybeConfigure(RuntimeConfigurable.java:390)
>>> The intent of Property.PropertyResolver is I think to remain in
>>> the Property task - the trace seems to imply that it has
>>> escaped from that task.
>> I think it is looping. There is a per-thread stack to detect this, but
>> it isnt working. Otherwise the loop wouldnt happen.
>>
>> This could be some wierd race condition in the JVM itself, which may be
>> reordering operations in the single thread. Remember, unless your
>> variable  is tagged as volatile, or the block is synchronized, Java can
>> swap the order of actions. It can even reorder volatile access in Java <1.5
> I know, but 1) I do not know why a ThreadLocal (shudder) is needed
> here, this means  that the code is more complicated than it needs to be.
> and

I presume its a way of preventing recursion down the resolution path. 
When I did something like this in some grid-standard XML variant of the 
smartfrog language I just passed the stack down as an explicit parameter.

I dont like threadlocals as they are a way to consume more memory than 
usual.

> 2) even with the above, the clone operation should have protected
> the rest of the system as the tasks deletete is only added to
> the cloned property helper which is local to the method.
> 

makes sense

> In any case, I think that the code is too slow for a very common code
> path in ant.
> 

well, let's get it working, then worry about performance. Actually, both 
may be the same solution. If we can move to a stack param then the 
concurrency logic changes.


-steve



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message