You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2014/04/03 19:53:14 UTC
[jira] [Updated] (UIMA-3722) JCasHashMap lifecycle size management
broken
[ https://issues.apache.org/jira/browse/UIMA-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor updated UIMA-3722:
---------------------------------
Description:
The code which decides whether or not the map table expansion is needed does
{code}
if (size >= sizeWhichTriggersExpansion) {
increaseSize();
{code}
but fails to then recalculate sizeWhichTriggersExpansion...
Additionally, the technique to save the last failed probe located empty cell is unreliable, because arbitrary user code could be run which might disturb this value, in the case where a new JCas cover class instance was constructed, and the class defined a "readObject()" method - this would be called and could execute aribtrary operations. Remove that optimization - have the put operation always do the find-empty-slot.
was:
The code which decides whether or not the map table expansion is needed does
{code}
if (size >= sizeWhichTriggersExpansion) {
increaseSize();
{code}
but fails to then recalculate sizeWhichTriggersExpansion...
> JCasHashMap lifecycle size management broken
> --------------------------------------------
>
> Key: UIMA-3722
> URL: https://issues.apache.org/jira/browse/UIMA-3722
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 2.6.0SDK
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Fix For: 2.6.0SDK
>
>
> The code which decides whether or not the map table expansion is needed does
> {code}
> if (size >= sizeWhichTriggersExpansion) {
> increaseSize();
> {code}
> but fails to then recalculate sizeWhichTriggersExpansion...
> Additionally, the technique to save the last failed probe located empty cell is unreliable, because arbitrary user code could be run which might disturb this value, in the case where a new JCas cover class instance was constructed, and the class defined a "readObject()" method - this would be called and could execute aribtrary operations. Remove that optimization - have the put operation always do the find-empty-slot.
--
This message was sent by Atlassian JIRA
(v6.2#6252)