I think Chad Loder wrote:
> Ernest,
>
> Have you considered implementing these things as memory-sensitive
> "memories" or caches, by taking advantage of Java's
> Soft/WeakReference framework? I haven't profiled Jess recently (the
> memory usage behavior is basically as you describe, it grows up to a
> certain point and then settles down).
I may just be "iggrn't," but it has always seemed to me that the whole
"weak reference" functionality in Java should have been a language
feature rather than an API thing. Creating a new Reference object on
the Java heap to track when some other object needs to be disposed
seems like a very heavyweight solution. In the present case, the
Tokens in the memory are themselves small, and so having a Reference
object to track each one would fairly double the memory consumption by
tokens. But as I said, maybe it's just me -- I've never really done
any work with the reference APIs.
> In other news, we're still seeing a weird Jess bug that causes
> (bind ?foo (call ...)) to sometimes return a java.lang.String object.
> I know it sounds crazy but that's the only explanation, and I think
> it has something to do with threading. I'm currently writing a Jess
> unit test that does lots of crazy asserts/rules/funcalls from
> many different threads and hopefully I can find a 100% reproducible
> case. Any advice?
>
Usually when (call) returns a String unexpectedly the String is "nil"
-- what (call) will return if the method returns null. Adding special
cases to the error messages (or some other similar change) so that
this is easier to see is someplace on my list of things to do. But
anyway, let's say you call something like
(call (call ?hashmap get MyReaderObject) close)
If there's no MyReaderObject key in the hash map, Jess's error message
will indicate that there's no "close" method in java.lang.String. This
is because HashMap.get() will return null, which Jess turns into the
symbol "nil", and then the outer call has to deal with that
symbol. First it looks for a class named "nil" with a static method
named close(). When it doesn't find such a class, the last attempt is
to call close() on the java.lang.String "nil", and that's where the
error message comes from.
---------------------------------------------------------
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]
--------------------------------------------------------------------
