Re: JESS: [EXTERNAL] Jess in a multithreaded environment

"Friedman-Hill, Ernest" <[email protected]> Thu, 3 Jan 2013 18:03:23 +0000
Newsgroups gmane.comp.java.jess
Message-ID <[email protected]>
Hi Wolfgang,=20

Jess needs a constant hashcode for any given object, so this mechanism
distinguishes between objects that provide their own constant hashcode an=
d
objects that can't be trusted to do so. The caching I was talking about
would be actually sorting objects into these categories right when the
jess.Value object is created, and storing the (constant) hashcode that wa=
s
determined. The only weak point in this is that it would force the user t=
o
establish that a class is a value class before any objects of that type
are referred to.

Another approach would be to use a lock-free container for that list of
classes (i.e., ConcurrentLinkedQueue) which retains that flexibility;
that's what we're actually trying first.


On 1/3/13 12:28 PM, "Wolfgang Laun" <[email protected]> wrote:

>Warning: I may have misunderstood the issue completely.
>
>If there is a list (or any other collection) maintaining the set of
>value classes, it stands to reason that it is synchronized for use in
>a multithreaded environment, and the contention for its lock may very
>well cause a performance hit.  If a lookup using this list is
>necessary for distinguishing between constant and non-constant hash
>codes, I don't see how caching a constant hash code may improve the
>situation.
>
>-W
>
>
>On 03/01/2013, Henschel, Joerg <[email protected]> wrote:
>> Yes, we (Software AG) have a source license, so it'd be great if you
>>could
>> provide a patch for this.
>>
>> Thanks!
>>
>> J=F6rg Henschel
>> Director Research & Development
>>
>> Email: [email protected]
>> Phone: +49 341 49287-700 | Fax: +49 341 49287-01
>>
>> itCampus Software- und Systemhaus GmbH | a Software AG Company
>> Nonnenstrasse 37 | 04229 Leipzig | Germany | http://www.itcampus.de
>> Amtsgericht Leipzig HRB 15872 | Managing Director: Guido Laures
>>
>>
>>
>> -----Urspr=FCngliche Nachricht-----
>> Von: [email protected] [mailto:[email protected]] =
Im
>> Auftrag von Friedman-Hill, Ernest
>> Gesendet: Dienstag, 18. Dezember 2012 19:50
>> An: jess-users
>> Betreff: Re: JESS: [EXTERNAL] Jess in a multithreaded environment
>>
>> Are you adding non-value classes to the list yourself, or is this just
>>with
>> the small number of default listings?
>>
>> This method will get called when you evaluate the hash code of a Java
>>object
>> in the Rete memory; this will happen often during pattern matching.
>>There's
>> actually enough room to cache the hash code in the members of the Valu=
e
>> class that are unused for Java object values, so we could try that as =
a
>> performance improvement.  Do you have a source license, so I could sen=
d
>>you
>> a patch to try?
>>
>> From: <Nguyen>, Son Nguyen
>> <[email protected]<mailto:[email protected]>>
>> Reply-To: jess-users
>> <[email protected]<mailto:[email protected]>=
>
>> Date: Thursday, December 13, 2012 11:04 AM
>> To: jess-users
>> <[email protected]<mailto:[email protected]>=
>
>> Subject: JESS: [EXTERNAL] Jess in a multithreaded environment
>>
>>
>>
>> Hi Jess experts,
>>
>> We use Jess in a multi-threaded environment and have experienced some
>> performance degradation when going from a single thread to multiple
>> threads.
>>
>> Our implementation uses the Slot Specific feature.
>>
>> Using a Java profiler, HashCodeComputer.isValueObject() stood out as
>>one of
>> the main contributing factors, if not the most likely,  to the
>>degradation
>>
>>
>>
>> --------------------------------------------------------------------
>> 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]=
v.
>--------------------------------------------------------------------



--------------------------------------------------------------------
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]=
.
--------------------------------------------------------------------