Thanks for confirming that stackoverflow is fixed. > I wait until Eclipse is finished building, force a few GCs, until memory usage > is stable and then make a heap dump. The heapdump shows about 700M used by > AjState objects. About 75% of this memory is taken by world.typeMap.tMap. For > the largest AjState, the expendableMap (I suspect that this is where the > demoted types move to) is very small in size (only 700k), but still contains > 5224 entries, according to the size field. I don't know if this number really > shows the number of entries in the map, because the size() method on > WeakHashMap first expunges stale entries. The tMap has a size of 1424.
I'm still surprised there is so much memory being held onto. I vaguely recall you were just using declare warning/error - or am I mistaken? The typemap 'tMap' field should hold onto: - primitive type representations - Object - aspects - types affected by intertype declarations from aspects and nothing else. 1424 does seem high as if you are using only declare warning that would suggest you have around 1415 aspects :) So something else must be going on. Andy On 2 September 2010 02:18, Emond Papegaaij <[email protected]> wrote: > On Friday 06 August 2010 18:20:01 Andy Clement wrote: >> Thanks for the feedback! >> >> On 6 August 2010 00:29, Emond Papegaaij <[email protected]> wrote: >> > Memory usage is down a bit (I'd say about 20%, compared to just >> > minimalModel=true). The largest AjState object went down from 250M to >> > just under 200M. Eclipse now takes just over 700M after a full GC, >> > compared to 850M without type demotion. >> >> Surprised it is only so little change. Were you leaving it for a >> while to ensure the JVM is fully cleaning up or just observing the >> heap usage straight after a build? Much of the state that was >> previously locked in memory is now free for GC through weak >> references, but their behaviour is unpredictable depending on the VM >> (in my experience). To check the true size I usually attach a >> profiler and force a few GCs, which then shows me the true minimal >> footprint. (Jconsole can also be used for the job, I imagine) > > I wait until Eclipse is finished building, force a few GCs, until memory usage > is stable and then make a heap dump. The heapdump shows about 700M used by > AjState objects. About 75% of this memory is taken by world.typeMap.tMap. For > the largest AjState, the expendableMap (I suspect that this is where the > demoted types move to) is very small in size (only 700k), but still contains > 5224 entries, according to the size field. I don't know if this number really > shows the number of entries in the map, because the size() method on > WeakHashMap first expunges stale entries. The tMap has a size of 1424. > >> >> - it breaks ! >> > >> > Yes, it breaks a lot unfortunately. I had to click away about 70 errors. >> > They all seem to be caused by a stack overflow: >> > at >> > org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:430 >> > ) at >> > org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:399 >> > ) at >> > org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:430 >> > ) at >> > org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:399 >> > ) etc. >> >> I've seen this before - it is because we are evicting something from >> memory that never used to be evicted but when we recover it, we don't >> recover it in exactly the same state. It only happens when generic >> types are used and due to the weak references being in the mix can be >> very hit and miss to recreate :( I'll think on this but without a >> test program that truly shows the issue, it'll be tricky to know for >> certain that I've nailed it. All my tests and sample projects work >> fine (*sigh*) > > In the latest build, this seems to be fixed. I no longer get exceptions during > compilation. > > Best regards, > Emond Papegaaij > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
