Hey Andy, So I've checked the build with only the minimalModel=true parameter but it seems to be the same time/memory consumption as building without it (some of the aspects in my project surely affects most of the classes) and there is GC thrashing with max heap of 1400MB. I guess the only option we have now is to use the type demotion with some implementation change so it would be more balanced between memory and speed.
Thanks, Gil 2010/10/10 Andy Clement <andrew.clem...@gmail.com> > Yes, that is the trade-off with using these options, speed vs memory - > but I'm not sure I would have expected them to be quite so exaggerated > for you! > > typeDemotion=true - means eagerly throw stuff away that we might or > might not need later. Without demotion you run with a large heap as > everything is kept around. With it turned on you are often throwing > things away you'll need again. It isn't a particular smart algorithm > right now though, I imagine we could apply some smarts to maybe keep > things around longer that seemed to be used frequently. > > minimalModel=true - this is not a trade off at all. This will save > memory *but* pieces of the model are only discarded (to save memory) > if they are not affected by ITDs or advice. This means if you have > aspects that hit only a few files in a large project, you can save a > load of memory, but if you have something like a tracing aspect that > hits 99% of your files, it won't save much at all. > > If you don't think all your files are being hit by advice/itds, I'd > recommend just using minimalModel=true, to see if it helps alleviate > the GC thrashing. Meanwhile it sounds like we should look at making > type demotion smarter so that it isn't such an extreme tradeoff. I > wonder what your build time would be without the heap thrashing, > whatever that number is, it ought to be achievable with an intelligent > type demotion algorithm. > > Andy. > > On 10 October 2010 04:45, Gil Sagi <gil...@gmail.com> wrote: > > Hey Andy, > > When I'm building the project without the heap optimization > > (-Xset:minimalModel=true,typeDemotion=true)the heap is reaching my max > > heapsetting (~1400) which causes the GC to run again and again which > seems > > to affect the performance and the full build takes about 8 minutes. > > Now when I'm trying to build with the optimization it seems there is a > big > > reduction in the heap usage but the build is very very slow and takes > more > > than 1 hour (it didn't finish yet...). > > So actually I cannot use this optimization although the heap state is > > absolutely better. > > Do you have any idea? > > Thanks, > > Gil > > 2010/10/10 Andy Clement <andrew.clem...@gmail.com> > >> > >> One thing: > >> > >> On 8 October 2010 09:32, Gil Sagi <gil...@gmail.com> wrote: > >> > Currently the Eclipse downside is the memory consumption of the > weaving > >> > process - it takes about 8 minutes and the heap is getting up to > 1400MB > >> > so > >> > restart the Eclipse from time to time is a use-case we cannot ignore. > >> > >> That is a long time for a full build... Is it by any chance due to > >> the heap getting relatively full and then GC thrashing going on? (so > >> not actually running out of memory, but running on the limit). If so > >> you could try those AJDT memory settings I mentioned in the 1.6.10 > >> readme, they should reduce the heap usage (if you try them and they > >> don't, that is interesting feedback...) - > >> http://eclipse.org/aspectj/doc/released/README-1610.html > >> > >> Andy > >> _______________________________________________ > >> aspectj-users mailing list > >> aspectj-users@eclipse.org > >> https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > > _______________________________________________ > > aspectj-users mailing list > > aspectj-users@eclipse.org > > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users >
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
