Sure, though not for a few days. I am in Hong Kong for a few days and my Spring hacking capabilities and inclination are back in Sydney :-)
I'd also like to see if something could be done to reduce the total footprint for a single ReflectionWorld, given Spring's typical usage patterns. I am guessing that the features of AspectJ that Spring is using originated from static compilation scenarios where caching everything for the lifetime of the JVM (eg compiler) didn't matter so much. This seems ill-suited for Spring's purposes, once Spring has decided that a type does, or does not, need an advice it would be much better if it could aggressively reclaim most of memory consumed by the type analysis. My reading of the heap dumps is that this is not happening, even with 1.6.10.RC1. jon. On 27/10/2010, at 22:51, Andy Clement <andrew.clem...@gmail.com> wrote: > Hi Jon, > > Nice - are you able to provide a similar patch for Spring 3? I'll > look to get it committed - I am a spring committer in my 'spare' time > :) > > Andy > > On 27 October 2010 02:09, Jon Seymour <jon.seym...@gmail.com> wrote: >> An update on this. By >> modifying Spring to force it to share PointcutParsers and hence >> ReflectionWorlds I was able to drop the total memory consumed by a simple >> scenario in the live application from 297MB to 170MB, a not insignificant >> saving. Details in the Spring issue. >> >> jon. >> _______________________________________________ >> 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
