Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: {Spam?} Re: [aspectj-users] AJDT and memory

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)

>> - you see a change in performance.  With the more eager eviction model
>> these options employ, there may be more messing around to compile
>> stuff  (probably only noticeable on full builds)
>
> The build seems a bit slower, but not much. It's still fast enough.

You can actually see the timings if you open the AJDT Event Trace view
which shows a 'time spent in AJDE' number which indicates how long was
spent compiling - that can help you compare.


>> - 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*)

thanks,
Andy


Back to the top