Skip to main content

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

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 <emond.papegaaij@xxxxxxxxxx> wrote:
> 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
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>


Back to the top