defender methods analysis, classloading and java.lang.StackOverflowError

[Keith McGuigan]

Hi Sergey -

Thanks for looking into this, I'll see if I can get your code into the 
repo.  But you'll have to attach it first :)

--
- Keith

On 3/14/2012 11:08 AM, Sergey Kuksenko wrote:
> 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.
>
>
>
>