Results I had yesterday were : 3.0-benjamin (built yesterday) : 14M/2488M in 5:23.389s (It probably swapped a lot) 3.0-beta-2 (downloaded few minutes ago) : 9M/125M built in 23.723s 2.2.1 : 67M/136M built in 30s
I only built one module : http://svn.exoplatform.org/projects/ecms/trunk/packaging/wcm/ear Its dependencies tree is horrible ! I used : MAVEN_OPTS = -Xshare:auto -Xms128M -Xmx4G -XX:MaxPermSize=256M (In theory Xmx = 1G but I increased it to 4G to fix the OOME) To build it and reproduce the issue you need this repo : http://repository.exoplatform.org/public/ (releases & snapshots) I will try to open the debugger this WE if I find few minutes. On Aug 7, 2010, at 1:26 PM, 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. > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
