Hi Lars,
You're in luck! One of the first things I did for 4.1b4 was turn the
atom table into an internal implementation detail of the Value class
(remember that the static int <-> String mapping is a sticking point
for Serialization, a much-requested feature.) Two things happened as a
result: the core code shrunk noticeably (5-10%) and the resulting
simplificiation enabled me to get a measurable speed improvement (also
5-10%.) By subsequently removing the atom table -entirely-, I only
gave back a few percent in performance, for an overall net gain!
Therefore, as of 4.1b4, which should be coming soon, there -is- no
atom table; no RU.putAtom(), no RU.getAtom(), etc. Atoms are now
stored as nicely serializable Strings, and unreferenced ones will be
garbage-collected.
This unfortunately all requires a bit of user-code change; in
particular, the Userfunction.name() method now returns a String, not
an int.
BTW: Any more info on the corrupted negcnt problem?
I think Lars Rasmusson wrote:
>
> Hi,
>
> I have a problem with a "memory leak". I'm writing an application that
> parses a lot of text (using a regular expression package called
> OROMatcher).
> I have jess functions calling the java functions to get the text and
> then
> I call the parse functions (also from Jess) to remove comments, extract
> values, etc.
>
> The problem is that whenever a string is sent to Jess it is added to the
> atom table (or JessHashtable as it is called). Since there is no atom
> table gc,
> all text is added indefinitely.
>
> Is there any (nice) way around this, or do I need atom gc?
>
> One solution could be to wrap all java-functions returning strings in
> functions
> returning Objects. Such values are not added to the atom table. But
> whenever
> the jess program needs to access the strings again they have to be
> converted
> back to strings and will inevitably be added to the atom table, as I
> understand it. That solution does not work for me, since I want jess to
> look at the text
> when it decides what java functions to call...
>
> Perhaps one could introduce a string type that is not asserted into the
> atom
> table? In many languages (like prolog) one distinguishes between atoms
> and strings... And even for them, one recently introduced atom gc
> because it was
> needed when one writes sever programs.
>
> /Lars Rasmusson
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list. List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
>
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (510) 294-2154
Sandia National Labs FAX: (510) 294-2234
Org. 8920, MS 9214 [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. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
