defender methods analysis, classloading and java.lang.StackOverflowError

Sergey Kuksenko sergey.kuksenko at
Wed Mar 14 08:08:54 PDT 2012

Hi All,

It is not a big secret that HotSpot do classloading of 
superclasses/superinterfaces recursively.
That means - for any fixed stack size there is classes/interfaces chain 
which causes java.lang.StackOverflowError
For example, on Linux x86-32, chain of 512 interfaces needs at least 
2.5Megabytes stack size using jdk7u2 (default stack size == 320k).
Maybe it is not a good idea to do classloading with recursion, but it is 
a topic for another mail list.

Let's back to defenders.
I was playing with interface chains. All interfaces (except the first) 
are empty. There are no defender methods here.
As result I've got on Linux x86-32:
- jdk7u2 requires ~4.8K per interface
- jdk8 requires ~5K per interface
- lambda build requires ~13K per interface.

Lambda's HotSpot requires 2.5 larger stack size settings than jdk8. This 
is really significant change. Jdk7 & 8 with default stack size (Linux32) 
may load chain of ~60 classes/interfaces, but lambda may load chain only 
of ~20 classes/interfaces. The source of that is declaration 
"GenericAnalyzer ga;" in the "ClassFileParser::parseClassFile" method 
and it doesn't matter that the declaration is inside never executed 
We may say "thank you" to gcc. I didn't check, but expecting the similar 
problem for other C++ compilers and platforms.

I've attached patch which solves that problem. Simple extracting couple 
lines of code into separate method bring back lambda to jdk8 stack size 

Best regards,
Sergey Kuksenko

More information about the lambda-dev mailing list