Well, I'm really just being a lazy programmer. I don't really need to redefine the same query; I could just use a map to point to previously defined queries. The queries come about because an interactive agent uses a policy to make decisions. This policy is made up of rules, the conditions of which I use to query the state to see if the rule is applicable.
'Why not just use rules?' you may ask. Well rules are checked when run is called (which BTW is at each state of the environment to assert extra information kept by environment rules), whereas queries are only checked when they are manually called. If an agent's policy was asserted as a rule, it would have to be retracted again when the policy changes. In any case, I'll stop being lazy with the query definitions and see what happens on that front. The environment in which that heap dump was generated from should have about 25 facts (thereabouts) and approximately 10 rules. And about 10 templates. So something is amiss here. The (facts) command only shows the facts that should be there (the approx 25 or so), so something internal is going on. I'll investigate the query redefinition problem and send my results. Ernest Friedman-Hill-3 wrote: > > Hmmm. The numbers don't mean anything specifically -- they're just a > way of creating unique symbols -- but the fact that they come one > after another this way finally makes me realize that you really did > mean you are redefining a query over and over again, hundreds of > times. Perhaps you *have* found a memory leak, because you're doing > something highly atypical. Why do you need to redefine the identical > query over and over again? > > On the other hand, perhaps the redefinition a red herring: if you're > automatically generating these, perhaps you're creating many, many > rules or queries that are *not* duplicates, and therefore running out > of memory? > > Looking at your heap dump info, it seems to suggest that you have > 47,000 live facts in working memory, and maybe somewhere between > 200-600 rules and/or queries. Does that align with your expectations? > > > On Feb 20, 2010, at 9:24 PM, Sam Sarjant wrote: > >> >> Hmm. I just came across something that could be the culprit. When >> creating >> the new queries which overwrite the old ones, upon examination of the >> 'ppdefquery <queryname>', I noticed that the '?' variable is >> assigned a new >> JESS name (an internal process). >> >> The possible problem I noticed was that this internal variable was >> incrementing with every redefinition of the query. For instance: >> >> "(defquery MAIN::polRule0 >> (on ?X ?_blank_396) >> (above ?X ?_blank_397) >> (clear ?X) >> (block ?X))" >> "(defquery MAIN::polRule0 >> (on ?X ?_blank_398) >> (above ?X ?_blank_399) >> (clear ?X) >> (block ?X))" >> "(defquery MAIN::polRule0 >> (on ?X ?_blank_400) >> (above ?X ?_blank_401) >> (clear ?X) >> (block ?X))" >> etc. >> >> Perhaps it's nothing, but if JESS is hanging on to these variables, >> it could >> become bloated. >> >> >> Ernest Friedman-Hill-3 wrote: >>> >>> The best thing to do would be to try to figure out where the memory >>> is >>> going, and whether it's a bug, or a normal consequence of how you're >>> operating. There's no reason why, given what you've described, memory >>> usage should increase over time, so there's either something you're >>> not telling me, or there's a bug someplace. Can you try to check it >>> out using any kind of a heap profiler? >>> >>> On Feb 17, 2010, at 10:43 PM, Sam Sarjant wrote: >>> >>>> >>>> Hi. I am using JESS to represent a relational environment for an >>>> agent to >>>> interact in (Blocks World, to be specific, if that helps). >>>> >>>> At each state, I am first resetting the Rete object and then >>>> asserting the >>>> state of the environment. From these assertions, further assertions >>>> are made >>>> by using rules which define extra predicates. For example, if I >>>> assert (on a >>>> b), I also create the (above a b) and possibly (clear a), depending >>>> on the >>>> exact state of the environment when (run) is called. >>>> >>>> Anyway, the agent receives this information, chooses an action to >>>> take, and >>>> the environment is updated again by resetting and re-asserting. >>>> >>>> While I could contain all operations within JESS in this particular >>>> environment, some Java code is required to be run during the process >>>> for >>>> other environments, so this is why I don't simply operate using >>>> assert and >>>> retract. >>>> >>>> Obviously this doesn't fit the idea that generally rule bases remain >>>> static, >>>> but the performance I get is reasonable. My problem lies in the fact >>>> that >>>> after several hundred (or perhaps thousand) of these assertion, >>>> resetting >>>> loops, Java or JESS runs out of memory and throws an >>>> OutOfMemoryException. >>>> The rules for defining extra predicates are asserted only once, but >>>> queries >>>> are asserted roughly each iteration for state matching, though they >>>> should >>>> be asserting over one-another (defqueries of the same name). >>>> >>>> Is there something I can do to 'flush' JESS, or stop it storing >>>> these reset >>>> assertions? Or would it be better to periodically create a new Rete >>>> object, >>>> load in the rules and continue? >>>> >>>> - Sam Sarjant >>>> -- >>>> View this message in context: >>>> http://old.nabble.com/OutOfMemory-after-multiple-assertions-resets-tp27634092p27634092.html >>>> Sent from the Jess mailing list archive at Nabble.com. >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> 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 >>> Informatics & Decision Sciences, Sandia National Laboratories >>> PO Box 969, MS 9012, Livermore, CA 94550 >>> http://www.jessrules.com >>> >>> >>> >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> 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] >>> . >>> -------------------------------------------------------------------- >>> >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/JESS%3A-OutOfMemory-after-multiple-assertions-resets-tp27634200p27662584.html >> Sent from the Jess mailing list archive at Nabble.com. >> >> >> >> -------------------------------------------------------------------- >> 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] >> . >> -------------------------------------------------------------------- >> >> >> >> >> -- >> View this message in context: >> http://old.nabble.com/JESS%3A-OutOfMemory-after-multiple-assertions-resets-tp27634200p27672530.html >> Sent from the Jess mailing list archive at Nabble.com. >> >> >> >> -------------------------------------------------------------------- >> 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 > Informatics & Decision Sciences, Sandia National Laboratories > PO Box 969, MS 9012, Livermore, CA 94550 > http://www.jessrules.com > > > > > > > > -------------------------------------------------------------------- > 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]. > -------------------------------------------------------------------- > > > -- View this message in context: http://old.nabble.com/JESS%3A-OutOfMemory-after-multiple-assertions-resets-tp27634200p27695397.html Sent from the Jess mailing list archive at Nabble.com. -------------------------------------------------------------------- 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]. --------------------------------------------------------------------
