First, you haven't told us what version of Jess you're using. If
you're using other than the newest version (6.1p8 or 7.0b5) please
upgrade and see if the problem persists. Further, make sure that if
your "Storage" class implements the "hashCode" method, that (in Jess
6) the hashCode isn't changing while the object is in working memory,
or (in Jess 7) if it is, you've properly informed Jess about this
class.
If you still suspect a leak somewhere, using a memory profiler is
generally the best way to answer questions about memory leaks; it
often happens that there's some small detail that you may have missed
in your program. The code you're shown should indeed make Jess forget
all about an object in working memory, but of course we haven't seen
(nor should we see) the whole application.
A poor-man's memory profiler is the finalize() method. Override
finalize() in Storage to print a message, call System.gc() a lot, and
watch for that message appearing. You should see it once for each
object that's successfully garbage collected.
There are certainly also legitimate reasons why a Jess program would
slow down over time that have nothing to do with memory leaks;
primarily that would be due to polynomial numbers of partial matches
as you accumulate more items in working memory. You could look at your
rules and see if you can't make the earliest patterns more specific.
I think Bogdan Werth wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hello Jess-list,
> since I didn't get any reply on my previous email and couldn't solve the
> problem on my own I post my question again.
> What do I need to viper all possible links to the shadow fact object so
> that it is cleaned by java garbage collector. I am running a joined
> RePast-Jess simulation and creation lots and lots of agents represented
> by shadow facts. After they died I need somehow to remove all the links
> to these objects in order to give it free for the destruction. Here is
> what I do:
>
> engine.executeCommand("(bind ?st (new Storage))");
> engine.executeCommand("(definstance storage ?st)");
>
> and this is how they suppose to disappear forever
>
> engine.executeCommand("(undefinstance ?stinst )");
> engine.executeCommand("(bind ?st nil) ");
>
> Apparently the simulation gets slower and slower towards the end. I
> assume that I am leaving something which still holds these objects. I
> might be wrong however and the reason for performance loss lies
> somewhere else.
>
> Kind regards for all the efforts in beforehand
>
>
> Bogdan Werth wrote:
> > Jess list,
> > the model I develop with RePast and Jess tends to get slower and
> > slower untill it runns into some heap space overflow. My suggestion is
> > that Java objects I've asserted with Jess are not decomposed by
> > garbage collector (again this is just a speculation).
> >
> > This is how I crate my shadow facts
> >
> > engine.executeCommand("(bind ?st (new Storage))");
> > engine.executeCommand("(definstance storage ?st)");
> >
> > and this is how they suppose to disappear forever
> >
> > engine.executeCommand("(undefinstance ?stinst )");
> > engine.executeCommand("(bind ?st nil) ");
> >
> > Is this enough? Does this means that next time the garbage collector
> > runns it will dispose the Storage object?
> >
> > Thanks.
> >
> >
> >
> >
> >
> >
> >
> > Bogdan Werth wrote:
> >> Solved my problem with assertion of the clean-up facts. Don't know
> >> whether this is the most elegant solution but certainly the one which
> >> works.
> >> By the way is there in Jess anything to delete queries? "undefrule"
> >> doesn't work for queries as I've noticed. I also couldn't find
> >> anything in the book on this topic.
> >>
> >> Bogdan Werth wrote:
> >>> I did follow the advise and made a really simple rule to retract
> >>> unused facts ... but this clean-up-rule fires sporadically. I can't
> >>> understand why. It fires every time if I have one agent but if I
> >>> have more than one agent it starts it's sporadic life. Can it be
> >>> that the clean-up-rule fires before the death rule and this causes
> >>> the problems?
> >>>
> >>> So here is my situation:
> >>>
> >>> (deftemplate person (slot householdID) (slot ID) ... (slot stl))
> >>>
> >>> (defrule deaths
> >>> ?id <- (person (householdID " + getID() + ") (ID ?number) ... (stl
> >>> ?stepsToLive))" +
> >>> =>
> >>> (if (<= ?stepsToLive 0)) then (retract ?id) else ())
> >>> )
> >>>
> >>> (defrule cleanUp
> >>> (not (person (householdID " + getID() + ") ))
> >>> =>
> >>> < do something >
> >>> )
> >>>
> >>> Any good suggestions (or mistakes in my code :-) )?
> >>>
> >>> Thanks in advance
> >>>
> >>>
> >>>
> >>> [EMAIL PROTECTED] wrote:
> >>>> I think Bogdan Werth wrote:
> >>>> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> >>>>
> >>>>> Hello Jess-list,
> >>>>> I wonder if it is possible to delete old rules/facts in a
> >>>>> while-loop if they all contain the same ID in either
> >>>>> rule-name or fact-name.
> >>>>>
> >>>>
> >>>> You could certainly use the Rete.listDefrules() method and look at the
> >>>> name of each Defrule object returned by the Iterator. It would be safe
> >>>> to hand the name of each rule to the Rete.unDefrule() method as you
> >>>> encounter it.
> >>>>
> >>>> For facts, if you can't simply have a rule which matches the facts you
> >>>> want to retract, you could use a defquery. That would give you access
> >>>> to all the matching facts, and again, you could retract them one by
> >>>> one.
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------
> >>>> Ernest Friedman-Hill Advanced Software Research Phone:
> >>>> (925) 294-2154
> >>>> Sandia National Labs FAX: (925) 294-2234
> >>>> PO Box 969, MS 9012 [EMAIL PROTECTED]
> >>>> Livermore, CA 94550 http://herzberg.ca.sandia.gov
> >>>>
> >>>> --------------------------------------------------------------------
> >>>> To unsubscribe, send the words 'unsubscribe jess-users
> >>>> [EMAIL PROTECTED]'
> >>>> in the BODY of a message to [EMAIL PROTECTED], NOT to the list
> >>>> (use your own address!) List problems? Notify
> >>>> [EMAIL PROTECTED]
> >>>> --------------------------------------------------------------------
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>
> --
>
> Bogdan Werth
> Doctoral Researcher Centre for Policy Modelling
> The Graduate School of Business
> Aytoun Building
> Aytoun Street
> Manchester
> M1 3GH
> UK
> Tel: +44 161 247 6481
> Fax: +44 161 247 6802
> Email: [EMAIL PROTECTED]
> Web: http://cfpm.org/~bogdan
>
> **************************************************************
> Before acting on this email or opening any attachments you
> should read the Manchester Metropolitan University's email
> disclaimer available on its website
> http://www.mmu.ac.uk/emaildisclaimer
> ***************************************************************
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the list
> (use your own address!) List problems? Notify [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Advanced Software Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://herzberg.ca.sandia.gov
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------
