Hi Alan,
Not really strange; it just means that Java has run out of
memory. Remember that the Rete algorithm trades space for speed -
i.e., it uses lots of memory so it can go fast. Your simple program
creates 10,000 facts, 10,000 partial matches and 10,000 activation
records simultaneously (and presumably a deffacts containing the
10,000 facts). Even if Jess created only one instance of
java.lang.Object (the smallest possible object) for each of these,
that'd still be about a megabyte for Sun's JVM. Jess uses far more
space than this, however, since each of these object has references to
other objects, contains arrays of such references,
etc. Conservatively, I'd day the average size of one of these objects
including all its subsidiary data is 400 bytes, which brings the total
size of your program's data up to 16 Megabytes - the maximum size of
the JVM's fixed heap (by default). Add in the size of the Jess code
and core data structures themselves, and you can see why Java runs out
of memory.
You can tell the JVM to allocate a bigger heap (if you've got the RAM)
using the -mx option: -mx 32m would double the default heap size.
I think Alan Barton wrote:
>
> Any thoughts on the following strange behaviour?
>
> I have a template of this form:
> ( deftemplate templateName
> (slot slotOne)
> )
>
> And I have one rule:
> (defrule oneRule
> ?factId <- (templateName (slotOne ?slotOne))
> =>
> (printout t ?factId "," ?slotOne crlf)
> (retract ?factId)
> )
>
> The rule simply matches ALL asserted facts and then prints and retracts the fact.
>
> STRANGE BEHAVIOUR:
> I am trying to assert 10,000 facts; for example...
> (assert (name (slotOne 0)))
> (assert (name (slotOne 1)))
> ...
> (assert (name (slotOne 9999)))
>
> and the Java Virtual Machine crashes, saying that I have run out of memory.
>
> Here is a stack trace:
> java.lang.OutOfMemoryError
> at java.lang.StringBuffer.append(Compiled Code)
> at jess.TextInputStream.appendText(Compiled Code)
> at jess.TextInputStream.read(Compiled Code)
> at java.io.StreamTokenizer.read(Compiled Code)
> at java.io.StreamTokenizer.nextToken(Compiled Code)
> at jess.JessToken.create(Compiled Code)
> at jess.JessTokenStream.prepareSexp(Compiled Code)
> at jess.JessTokenStream.eof(Compiled Code)
> at jess.Jesp.parse(Compiled Code)
> at jess.Rete.executeCommand(Compiled Code)
> at some of my wrapper code called here...
>
> Do you know why, over time, the VM runs out of memory? and how I can
> stop this from occuring? (I have tried System.gc() after a Rete.executeCommand(),
> but that does not help.)
>
> Thank you,
> Alan.
>
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list. List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
>
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (510) 294-2154
Sandia National Labs FAX: (510) 294-2234
Org. 8920, MS 9214 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
