Thanks for the fast reply and sorry for misleading information.
Florian, ?st and ?stinst is a typo. I can neither see the facts anymore
nor match them with the rule but the simulation is getting slower with
the time. That is why I thought that Jess might still hold some links to
the objects. After I changed finalize I can see that the objects are
retracted.
I think the most sensible thing would be to play around with JMP(java
memory profiler). I will post to the mailing list whether it was Jess or
the programmer who slowed down the system :-)
Many thanks.
[EMAIL PROTECTED] wrote:
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]
--------------------------------------------------------------------
--
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]
--------------------------------------------------------------------
