defender methods analysis, classloading and java.lang.StackOverflowError

Keith McGuigan keith.mcguigan at
Wed Mar 14 09:32:39 PDT 2012

On 3/14/2012 12:12 PM, Sergey Kuksenko wrote:

>> ... because then we'll use less room in parseClassFile()'s stack.
> We may try this.
> But I suspect not only impact of GenericAnalyzer size. The problem may
> be caused by aggressive inline and corresponding stack frame expansion.

Yeah, that's a good point.  I'll fire it up in a debugger sometime and 
see if I can tell what's going on.

> ParseClassFile() is too big - ~900 lines.
> IMHO the method should be split.
>>    But I
>> don't think that's going to explain the ~8K/frame difference you're
>> seeing.  That's probably coming from within the GenericAnalyzer itself
>> (which does use recursion too).
> No. The branch "if (has_default_methods&&  !access_flags.is_interface())
> {" is never executed for that test.

Ok well that's good.  We'll probably have to revisit some of those 
algorithms though, to remove the recursion there too.

- Keith

More information about the lambda-dev mailing list