defender methods analysis, classloading and java.lang.StackOverflowError

[Sergey Kuksenko]

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 
scope/block.
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 
requirements.

-- 
Best regards,
Sergey Kuksenko