ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <peter.kitt.rei...@gmail.com>
Subject Re: AW: ant really slow, 100% CPU?
Date Mon, 24 Sep 2007 12:06:35 GMT
On 9/21/07, Steve Loughran <stevel@apache.org> wrote:
> 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.

I have made a modification to the way properties are expanded, so
hopefully this should be resolved.

Peter


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

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


Mime
View raw message