After running the default Java heap profiler 'hprof' I came up with some
results. Here's a small subset of the relevant part of the results:
SITES BEGIN (ordered by live bytes) Sat Feb 20 13:13:46 2010
percent live alloc'ed stack class
rank self accum bytes objs bytes objs trace name
1 6.70% 6.70% 3046032 126918 3148056 131169 302210 jess.Token[]
2 6.69% 13.38% 3042752 190172 3235184 202199 302186 jess.cg
3 5.82% 19.20% 2646784 47264 52158792 931407 302162 jess.Value[]
4 5.82% 25.02% 2646560 47260 52155992 931357 302178 jess.Value[]
5 4.99% 30.01% 2268672 47264 44707536 931407 302161 jess.Fact
6 4.17% 34.18% 1898520 47463 40129320 1003233 302164 jess.Token
7 3.32% 37.51% 1512416 47263 29803424 931357 302179 jess.Value
8 3.10% 40.61% 1411432 58796 1705072 71031 302187 jess.Token[]
9 2.15% 42.75% 975840 40660 975840 40660 302146
java.util.HashMap$Entry
10 2.11% 44.87% 961792 15028 972416 15194 302157 jess.q[]
11 2.03% 46.90% 922624 14416 972416 15194 302155 jess.q[]
12 1.87% 48.76% 849376 9205 2220192 32790 302537 jess.Token[]
13 1.66% 50.43% 756208 47263 14901712 931357 302177 jess.ValueVector
14 1.62% 52.05% 737440 18436 184075760 4601894 302224 jess.Token
15 1.34% 53.38% 607760 15194 607760 15194 302154 jess.e0
These seem to indicate that JESS is creating a lot of Tokens and Values. I
have a feeling these are a result of the frequently re-defined queries being
evaluated at every step. I wasn't able to use the heap trace to figure out
where the code goes wrong though.
I'm stuck for ideas, so I may just side-step the issue by recreating the
Rete object at set intervals, thusly destroying any data in the old Rete
object.
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].
--------------------------------------------------------------------
