On Aug 7, 2010, at 7:26 AM, Brett Porter wrote: > > On 07/08/2010, at 12:44 AM, Arnaud Héritier wrote: > >> The advantage is to do what I did this morning in few minutes. >> I found a OOME on Aether/Guice branch (reported to benjamin but not in MNG >> because it's not yet integrated) and then I validated it wasn't here in >> current trunk. >> The problem is that I had to rebuild both of them hat users won't do. >> Without the beta2 release, each time you'll have to check if the problem >> reported comes from Guice/Aether or from changes done for now in beta2. >> It is more for you who'll work on it to easily ask a comparison. > > I ran this over one of my builds out of curiosity. Not sure if this is > helpful, but maybe some datapoints. > > 3.0-benjamin => 73m / 252m > 3.0-beta-1 => 63m / 159m > 2.2.1 => 129m / 252m > > Then I checked just the following: > 3.0-beta-2-SNAPSHOT + guice patch => 70m/218m > 3.0-beta-2-SNAPSHOT => 74m/252m > > The numbers are quite consistent, so it looks like the problem might have > been on trunk here, not the guice++ branch. Arnaud, is that also what you see > with trunk? > > I quickly ran the first two with Yourkit and saw that in Benjamin's branch, > the memory grows faster at a consistent rate, but is still released at the > end. The retained memory is only the classrealms and JDK ZIP cache, which > basically is the same for beta-1. So more usage, but not a leak. No OOME, but > perhaps the project is not big enough to exhibit it. > > Nothing to particularly note on the garbage collection front. The non-heap > memory looks to be identical. Basically the same results running with a clean > repository to do more artifact operations. Scanning the allocations, there's > quite deep trees of allocations for Guice & the shim - but given the results > for the other snapshots I'm not sure that's an issue itself. >
Yes, we believe there are no GC or leakage issues with the Aether it is the dirty tree which is memory intensive and it's that structure we are trying to compact. The performance framework found the intense memory use instantly. It was reduced and now we're thinking of trying to use a graph structure for the dirty tree. We're not sure if this will work or not yet. > That's all I had time for, but I'll hold onto the snapshots in case they help. > > - Brett > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- Three people can keep a secret provided two of them are dead. -- Unknown
