This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: limit to length of an s-expression passed to eval?
- From: Per Bothner <per at bothner dot com>
- To: alex mitchell <lexaay at gmail dot com>
- Cc: "kawa at sourceware dot org" <kawa at sourceware dot org>
- Date: Thu, 17 Nov 2011 18:16:16 -0800
- Subject: Re: limit to length of an s-expression passed to eval?
- References: <CAEBD5FA.25E71%lexaay@gmail.com>
On 11/17/2011 05:29 PM, alex mitchell wrote:
gnu.text.SyntaxException:
<unknown>: internal compile error - caught java.lang.ClassFormatError:
Invalid method Code length 65753 in class file atEvalLevel$333
java.lang.ClassLoader.defineClass1(Native Method)
java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
java.lang.ClassLoader.defineClass(ClassLoader.java:615)
java.lang.ClassLoader.defineClass(ClassLoader.java:465)
gnu.bytecode.ArrayClassLoader.loadClass(ArrayClassLoader.java:134)
gnu.expr.ModuleExp.evalToClass(ModuleExp.java:115)
gnu.expr.ModuleExp.evalModule1(ModuleExp.java:221)
gnu.expr.ModuleExp.evalModule(ModuleExp.java:175)
kawa.lang.Eval.evalBody(Eval.java:101)
kawa.lang.Eval.eval(Eval.java:29)
kawa.lang.Eval.eval(Eval.java:57)
evaluator.myeval(evaluator.scm:21)
I can get around this by removing the top-level "begin", and saving a
series of s-expressions to the file, rather than a single s-expression.
However, its much easier to pass around a single s-expression internally,
which I can then write out directly to file, rather than generating a list
of s-expressions which I will then have to step through and write
sequentially to the file.
It looks like I'm hitting this bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4262078. Is there any
way around this limit besides what I suggested above?
You could try tweaking the alwaysCompile field in gnu/expr/ModuleExp.java.
Perhaps that could be tied to a command-line flags or a compiler-option.
However, there are good reasons for alwaysCompile to default to true:
If generally make Kawa behavior more consistent, and specifically exceptions
provide more useful stack-traces.
It is no doubt possible to be smarter and split up long methods etc.
However, that is a pain and I keep hoping one of these days bug 4262078
will be fixed. (Though it won't happen in Java 8.)
--
--Per Bothner
per@bothner.com http://per.bothner.com/