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].
--------------------------------------------------------------------
