ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
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 <> wrote:
>> Peter Reilly wrote:
>>> 1) Some of the traces seem to imply a bug.
>> clearly :)
>>>         at
>>>         - locked <0x00002aaab4013548> (a
>>>         at
>>>         at
>>>         at
>>> 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 

> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message