On Sun, Jan 18, 2009 at 1:28 PM, Erik Huelsmann <ehuels@...> wrote:
> Hi Don,
> On Sun, Dec 28, 2008 at 10:24 PM, Don Cohen
> <don-sourceforge-xxz@...> wrote:
>> (Sorry, I was away from the net for a few days.)
>> Erik Huelsmann writes:
>> > > I'm able to consistently find myself with an "Out of memory: Java heap
>> > > space" exception, so it looks like I'm able to reproduce. However, I'm
>> > > not exactly sure where in the compilation process this error occurs:
>> > > it might be in a compile phase or in a loader phase. Anyway: are you
>> > > allocating huge integers, possibly many of them? I'm finding myself
>> > > with the OOM in this line (in BigInteger.java:2021):
>> My impression was that the error occurred inside compile-file.
>> I do normally load the compiled file after compiling it, but that
>> would normally be preceded by the message saying that we're loading.
>> Now that I look, it does seem odd that the output looks like this:
>> ; (DEFUN TREEDELETER ...)
>> ; (DEFUN TREETESTER ...)
>> ; (DEFUN TREEGENERATOR ...)
>> ; Compilation unit finished
>> ; The following functions were used but not defined:
>> ; ARITY*
>> ; GET-COMPARISONS-AND-CANONICALIZERS
>> Debugger invoked on condition of type ERROR:
>> Out of memory.
>> whereas the source file contains
>> (defun treedeleter (tuple tree compare-rels &aux subtree)
>> (defun treetester (tuple tree compare-rels)
>> (defun treegenerator (subsetflg vars rel &rest args &aux stored
>> (defun fix-tree-equiv (rel temp)
>> and many more functions.
>> So something is going wrong before, perhaps even in reading the file.
> Ok. I have some more outcomes (sorry for the slow pace): The file is
> being read correctly. The problem is in the handling of the
> compilation step of ASH: DERIVE-TYPE-ASH is doing some ASH operations
> of itself. One of the shift operations is trying to shift '1' by
> 2147483646 positions. It seems the BigInt can't accomodate that much
> space :-)
> Ville, you recently organised code related to the (when-args-integer
> ...) stuff. Can you comment on what that function is doing, possibly
> even finding where we're doing this extreme shift? I mean, it's not
> really usefull to calculate that number, right? Better to say (INTEGER
> 2 *) or something like it.
> I'll try to find out what the usefull bounds of INTEGER are for the compiler.
Well, this issue is now fixed in trunk/. I hope you have more success
with AP5 now.
Thanks for your report. I'm looking forward to any further reports if
you have them!