Re: (another?) VerifyError with kawa-1.6.70

[Per Bothner <per at bothner dot com>]

John Kozak <jk@noontide.demon.co.uk> writes:

> under IBM JDK 1.1.8 (and slightly more informative msgs under later
> JDKs).  Seems to provoked by the find-trans! code.

Correct.  Specifically, the compiler is not generating correct code to
load the closure environment that the lambdas inside fire-trans! need
to return to variables local to make-petri.  The bug is triggered by
the fact that fire-trans! is inlined, but the lambdas inside are not.
If you replace the for-each calls by a do or let loop, then I
believe the bug would not be triggered.  Of course the compiler should
do that - and we now have the framework to do so, by using the relatively
new gnu.expr.CanInline interface.  (A job for a volunteer?  If so,
I'll advise.)

The patch below seems to fix the problem.  Unfortunately, it does
cause some test-cases to fail.  This is a painfully complex part
of the compiler.  Last week I've decided to change how Kawa handles
closures, in a way that should hopefully solve various problems.
It may slow down calls to nested procedures in a few cases, but it
simplifies things, reduces the number of classes generated, and
will make it easier to implement full call/cc.  Therefore I'm not
going to bother with a correct fix for this bug until the re-write.

Index: LambdaExp.java
===================================================================
RCS file: /cvs/kawa/kawa/gnu/expr/LambdaExp.java,v
retrieving revision 1.43
diff -u -r1.43 LambdaExp.java
--- LambdaExp.java	2000/10/15 18:51:05	1.43
+++ LambdaExp.java	2000/11/22 04:55:45
@@ -481,9 +481,8 @@
     if (closureEnvField != null)
       {
 	code.emitDup(new_class);
-	LambdaExp caller = outerLambda();
-	code.emitLoad(caller.heapFrame != null ? caller.heapFrame
-		      : caller.closureEnv);		      
+	LambdaExp caller = outerLambdaNotInline();
+	caller.loadHeapFrame(comp);
 	code.emitPutField(closureEnvField);
       }

-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/