Thank you for your response.
I now have 2 questions for you :)
1) Is there a conference for JESS users or a regular/annual gathering?
2) What exactly does a retract do?
I have performed some tests with the following results...
Rule for Test 1: Match all facts in the fact list then print the fact.
Rule for Test 2: Match all facts in the fact list then print the fact and retract the
fact.
For test 1: I would expect (if I have 16m of RAM and 10,000 facts are
asserted) that I would run out of memory... as you stated...
For test 2: I would expect (if I have 16m of RAM and 10,000 facts are
asserted) that I would NOT run out of memory because I am
under the impression that the fact is completely deleted from the
Rete network and hence should require no more memory.
Thank you for clearing this up,
Alan.
PS I have successfully increased the VM's heap to 64m with no problems.
Ernest Friedman-Hill wrote:
> 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.
> >
> > BEHAVIOUR:
> > I am trying to assert 10,000 facts; for example...
> > (assert (templateName (slotOne 0)))
> > (assert (templateName (slotOne 1)))
> > ...
> > (assert (templateName (slotOne 9999)))
> >
> > and the Java Virtual Machine crashes, saying that I have run out of memory.
> > 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]
---------------------------------------------------------------------
