improved data-flow analysis for Kawa

[Per Bothner]

On 04/23/2011 08:59 AM, Helmut Eller wrote:
> * Per Bothner [2011-04-23 14:58] writes:
>
>> On 04/23/2011 01:17 AM, Helmut Eller wrote:
>>> It's still very big after that.  And I can remove parts in a dozen
>>> different places to toggle between failing/non-failing.
>>>
>>> If I increase the JVM stack size to 350k it succeeds.  Does the new pass
>>> just need a lot more stack or do I see a bug?

I played around with it a bit, and didn't see anything obviously wrong.

I was able to avoid the StackOverflow during the InliningCalls phase,
using either of:
(1) Change Kawa's InlineCalls to not descend into a function (in some 
situations);
or:
(2) Replace lambda-apply in one of the macros in your source.

But then I got the StackOverflow using the compilation (byte-code 
generation)
stage.  Again, the overflow happens when inlining a function that has only
a single (non-tail) call-site.  Obviously, this optimization is pretty
important, as it is needed to compile Scheme loops (named-let and do) 
efficiently.
Now it might be possible for Kawa to have some kind of nested inlining limit
(which might also help in avoiding over-big methods), but it might be 
tricky.
We want to avoid creating closures, which could be done by passing 
referenced
read-only variables as extra parameters.

The problem is this could take a fair amount of work, and as this is 
only an issue
for rather complicated code and the work-around (pass an extra -XssNNNNk 
parameter
to Java) is fairly simple, I think it makes most sense to live with it 
for now.
(If more people start running into this, then we might re-consider.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/