I don't know if there is a problem beyond what is described in Ernest's
earlier post but this should clear some things up for you (I am including
the post here since I couldn't find a link to it in the archives... go
figure):
Good luck!
alan
**** Ernest's post from 7/3/02 ****
Hi,
Well, this sounded like a very specific problem report, so I had to
try it. I first wrote a program precisely as you describe below, and I
didn't see the problem. Then I added a definition for a single rule
that matched the definstances, and suddenly I did see exactly what you
observed. I then ran the program under OptimizeIt to have a closer
look (OptimizeIt is a fantastic tool, by the way) and soon realized
what's going on. Here's the heart of this test program:
Rete r = new Rete();
r.defclass("MemTest", "MemTest", null);
r.executeCommand("(defrule test-rule (MemTest (val ?val)) =>
)");
for (int i=0; i<500; ++i) {
for (int j=0; j<10000; ++j) {
MemTest mt = new MemTest();
r.definstance("MemTest", mt,
true, r.getGlobalContext());
r.undefinstance(list.get(j));
}
}
As is sometimes the case with little test programs, this one is
pathological. Note that every time through the inner loop, an
activation is added to the agenda, and then removed. It turns out that
when a rule is activated in Jess, a jess.Activation object
representing the match is put into the data structure that represents
the agenda. If that rule is later deactivated, the jess.Activation is
*not* immediately removed; it's merely marked as inactive. When Jess
is running (i.e., if you've called "run") then inactive activations
are actually removed from the agenda as they're encountered. So in
other words, if an undefinstance() call results in rules being
deactivated, then a jess.Activation, which ultimately holds a
reference to the undefinstanced object, will still be reachable from
the agenda. It won't be cleaned up until that deactivated activation
is examined by the run loop.
So to modify the little sample program such that it doesn't run out of
memory, just add a "r.run()" just inside the end of the outer loop. My
version then has a peak RSS of 19M and runs to completion.
What does this say about your original application, which was having
memory problems? Well, one of two things, I suppose. First, there's
what I already explained about the plateau. Try putting the
node-index-hash declarations into your real program and see if it
brings things under control.
Otherwise, it may be that you've got a kind of pathological system
that is adding and removing definstances faster than the run loop can
drain the agenda. If you're using run-until-halt, maybe that thread's
priority is too low? Otherwise, you may need to call run() more often,
or if you're calling run(int), with a larger argument.
> -----Original Message-----
> From: James Gallogly [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 18, 2002 3:00 PM
> To: [EMAIL PROTECTED]
> Subject: JESS: retracted facts seem to hang around
>
>
>
> My goal is to serialize the Rete. I am definstanceing a Fact
> based off of a
> non-serializble object, doing a bunch of stuff, then
> undefinstancing the
> non-serializble objects Fact just before Serializing the
> Rete. I get an
> exception thrown saying it was unable to Serialize the
> non-serializable
> object. This implies that somehow a reference to this
> retracted fact is
> hanging around in the Rete and is attempting to be serialized.
>
>
> We had implemented the change described below with version
> Jess60 and it
> fixed the problem,
> We have now moved to Jess6.1a1 and while this exact fix is in
> there it seems
> a different reference to the retracted fact now remains. I
> also tried this
> with
> the Jess6.1a2.jar and the problem exits there as well,
> although I do not
> have
> the source to verify if the fix below is still intact. I will
> try and get
> more
> info to where specifically the reference is being held I was
> hoping this was
> a
> known issue, or that knowing what has changed between
> versions can assist in
> tracking it down. Thank so much for your any help.
>
> Jim
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On
> Behalf Of [EMAIL PROTECTED]
> Sent: Tuesday, April 02, 2002 9:34 AM
> To: [EMAIL PROTECTED]
> Subject: Re: JESS: Defrules keep references to retracted facts
>
>
>
> I'm actually aware of this and the fix is going to be in the next
> release. The patch involves replacing three methods in
> jess/TokenVector.java with new versions:
>
> final void clear() {
> if (m_ptr > 0) {
> Arrays.fill(m_v, 0, m_ptr, null);
> m_ptr = 0;
> }
> }
>
> final void removeElementAt(int i)
> {
> m_v[i] = m_v[m_ptr-1];
> m_v[--m_ptr] = null;
> }
>
> final void removeElement(Token t)
> {
> for (int i=0; i<m_ptr; i++)
> if (t.dataEquals(m_v[i]))
> {
> removeElementAt(i);
> return;
> }
> }
>
>
>
>
>
> I think Ian de Beer wrote:
> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > Hi
> > We noticed when running a profiler on our application that
> even though we
> > retract / undefinstance facts that are no longer used, jess
> retains a
> > reference to those facts, therefore preventing the garbage
> collector from
> > releasing heap space. This cause our application to
> steadily outgrow
> > available memory.
> > Is there a way of clearing old references from defrules
> while running Jess
> > in run-unit-halt mode - _reset_ seems to be an obvious way
> to do just
> that,
> > but when is an opportune time to that, if you are
> constantly asserting new
> > facts?
> > Regards
> > Ian
> >
>
>
>
> ---------------------------------------------------------
> Ernest Friedman-Hill
> Distributed Systems Research Phone: (925) 294-2154
> Sandia National Labs FAX: (925) 294-2234
> Org. 8920, MS 9012 [EMAIL PROTECTED]
> PO Box 969 http://herzberg.ca.sandia.gov
> Livermore, CA 94550
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
