That’s what I’d expect too
although I’m surprised at the error as reported: the method with the
stack overflow isn’t in a new thread, so why would increasing –Xmx avoid
a stack overflow if stack is all allocated up front?
I do know that it’s a weak map and
for a good reason: this allows the collector to release duplicate bytecode data
and other information. Without using a weak map, you get greater memory
overhead from load-time weaving.
From:
aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Kevin F
Sent: Thursday, March 29, 2007
4:57 PM
To: aspectj-users@xxxxxxxxxxx
Subject: Re:
[aspectj-users]java.lang.StackOverflowErroratorg.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:292)
Unless you’re talking about a
really strange VM with which I am unfamiliar, the VM allocates the entire stack
allocation size each time a thread is started. No additional allocations
take place for the stack itself; i.e., it will not grow.
I guess I am left wondering why type maps are being stored in a WeakHashMap
instead of a strong one.
Just my 2 cents,
Kevin
From: Ron Bodkin <rbodkin@xxxxxxxxxxxxxx>
Organization: New Aspects of
Software
Reply-To: <aspectj-users@xxxxxxxxxxx>
Date: Thu, 29 Mar 2007 12:39:26
-0700
To: <aspectj-users@xxxxxxxxxxx>
Subject: RE:
[aspectj-users]java.lang.StackOverflowError
atorg.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:292)
Interesting. I wouldn’t have expected that,
but perhaps the VM ran out of heap memory in allocating a stack frame and
because it ran out of memory it reported stack overflow.
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx]
On Behalf Of Santiago Aguiar
Sent: Thursday, March 29, 2007
12:33 PM
To: aspectj-users@xxxxxxxxxxx
Subject: Re:
[aspectj-users]java.lang.StackOverflowError atorg.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:292)
Hi Ron!
Thanks a lot for the reply!
The strack trace is of 1024 function calls... it seems a bit too deep for me (I
didn't paste the full stack trace in the email).
I tried your suggestion and it didn't work. However it made me thing and I
added -Xms128m -Xmx256m (since I'm passing those parameters when running in a
lab where I don't get the error) and it solved the problem.....
I don't exactly see why having less available memory would result in a
StackOverflow instead of an OutOfMemory error.....
Ron Bodkin wrote:
Hi Santiago,
You might try running your test with a larger stack size, since this
doesn’t look like an infinite loop. Try adding a VM argument
–Xss2048k to your junit runner to do this. This value is four times the
default, so you probably can run with less, but doing this should test whether
this fixes the problem (as I suspect it will). Java programs with deep stacks
sometimes need a larger value here. And running from Eclipse has different
stack depths, so the discrepancy isn’t too surprising.
From:
aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx]
On Behalf Of Santiago Aguiar
Sent: Thursday, March 29, 2007
8:39 AM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users]
java.lang.StackOverflowError
atorg.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:292)
Hi,
I'm using AspectJ 1.5.3 using LTW and writing *most* of my aspects code style.
I get the following stack trace when running a test case from ant:
[junit] java.lang.StackOverflowError
[junit] at
java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:269)
[junit] at java.util.WeakHashMap.getTable(WeakHashMap.java:297)
[junit] at
java.util.WeakHashMap.get(WeakHashMap.java:341)
[junit] at
org.aspectj.weaver.World$TypeMap.get(World.java:967)
[junit] at
org.aspectj.weaver.World.resolve(World.java:250)
[junit] at
org.aspectj.weaver.World.resolve(World.java:191)
[junit] at
org.aspectj.weaver.UnresolvedType.resolve(UnresolvedType.java:662)
[junit] at
org.aspectj.weaver.ReferenceType.getRawType(ReferenceType.java:550)
[junit] at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:292)
[junit] at
org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:276)
[junit] at
org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:292)
.....
Strangely, I don't get the error if running my test cases from inside Eclipse.
If I'm not wrong, eclipse uses it's own compiler while when running from ant
I'm compiling with Sun's compiler (1.5.0_09).
I don't really know what else to do... I suspect the issue is while handling
generics, but not much else. I'm willing to provide any additional information
to help me diagnose the problem.
I'm attaching the generated ajcore files.
thanks a lot,
saludos
--
santiago aguiar
netlabs
Palmar 2548
Montevideo, Uruguay
Tel. +(598 2) 707 7687
Fax. +(598 2) 709 4866
http://www.netlabs.com.uy
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
--
santiago aguiar
netlabs
Palmar 2548
Montevideo, Uruguay
Tel. +(598 2) 707 7687
Fax. +(598 2) 709 4866
http://www.netlabs.com.uy
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users