Re: [aspectj-users] AJDT and memory

[Emond Papegaaij <emond.papegaaij@xxxxxxxxxx>]

On Friday 06 August 2010 18:20:01 Andy Clement wrote:
> Thanks for the feedback!
> 
> On 6 August 2010 00:29, Emond Papegaaij <emond.papegaaij@xxxxxxxxxx> 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