[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-lambda-dev
Subject:    defender methods analysis, classloading and java.lang.StackOverflowError
From:       keith.mcguigan () oracle ! com (Keith McGuigan)
Date:       2012-03-14 16:32:39
Message-ID: 4F60C827.2010103 () oracle ! com
[Download RAW message or body]



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

[prev in list] [next in list] [prev in thread] [next in thread]