[jira] [Resolved] (UIMA-3619) improve Cas FS to JCas cover instance map

["Marshall Schor (JIRA)" <de...@uima.apache.org>]

     [ https://issues.apache.org/jira/browse/UIMA-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marshall Schor resolved UIMA-3619.
----------------------------------

    Resolution: Fixed

Changes: switched to internal hash code derived from murmurhash3 (in public domain); this eliminates all volatile / atomic operations.  Changed the hash bucket collision algorithm to one that is more favorable to L1/L2/L3 caches - using triangular numbers. For the case where a lookup fails, and then a new cover instance is added to the table, avoided re-looking up to find the spot to add the new item.

> improve Cas FS to JCas cover instance map
> -----------------------------------------
>
>                 Key: UIMA-3619
>                 URL: https://issues.apache.org/jira/browse/UIMA-3619
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>    Affects Versions: 2.5.0SDK
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>            Priority: Minor
>             Fix For: 2.5.1SDK
>
>
> In highly parallel environments running on multiple cores, profiling shows that the JCas map has performance issues due to volatile and atomic operations that are unneeded, but happen due to the use of the built-in Java Random function (which uses volatile and atomic operations, internally). This map doesn't need to support multi-threading operations - it is always used in a single-thread manner. Other optimizations are possible, due to the limited way this table is used.  One of the common cases is an iterator fetching an existing FS from the CAS, and needing to supply the corresponding JCas object (if it exists).  This operation first looks up in the Map using the address as the key, and if not found, then makes the JCas object, and then adds it to the map - an operation which repeats the same lookup in order to find the "empty slot" where it can store the item.  This extra lookup can be eliminated.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)