And I've got enough information from this to track down the real cause
of the problem; there is indeed an unintended memory leak in Jess when
you redefine a rule in a "live" system. It will be easy to fix. We do
have a new release coming out soon so this fix will be in it.
On Feb 22, 2010, at 7:56 PM, Sam Sarjant wrote:
Haha! While I haven't run extensive tests, the problem appears to be
solved.
By only defining a query once, things seem to be proceeding
normally. The
heap dump still has JESS's token's on top, but they no longer hold a
large
majority share of resources.
I was under the impression that if a defquery was defined under the
same
name as another, the older one would be overwritten. Perhaps this is
a bug,
or perhaps I was simply misled towards this impression.
Thanks for your help in this. I hope the rest of my JESS use stays
problem-free.
Sam Sarjant wrote:
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-tp27634200p27696537.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 Phone: (925) 294-2154
Sandia National Labs
PO Box 969, MS 9012 [email protected]
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].
--------------------------------------------------------------------
