uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Closed] (UIMA-4824) uv3 change storage model to always use int and ref arrays
Date Tue, 06 Dec 2016 15:16:58 GMT

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

Marshall Schor closed UIMA-4824.
--------------------------------
    Resolution: Fixed

> uv3 change storage model to always use int and ref arrays
> ---------------------------------------------------------
>
>                 Key: UIMA-4824
>                 URL: https://issues.apache.org/jira/browse/UIMA-4824
>             Project: UIMA
>          Issue Type: Sub-task
>          Components: Core Java Framework
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>            Priority: Minor
>             Fix For: 3.0.0SDKexp
>
>
> The first design for uv3x supported two different styles of storing data.  One style,
done for cases where there was no corresponding JCas definition for a feature, was to store
the feature value either in _intData or _refData arrays.  The other style was to have a field
in the JCas definition for the item; for example, a string value would be stored in a locally
declared String field.
> The JCas API would directly get/set the field in this case.  The Plain API would test
for a method handle in the Feature Impl, which would be set if there was a JCas field implementation;
otherwise it would inherit the general set/get code that used the storage in the _intData
or _refData.
> The method handle approach was very efficient - Eclipse single step showed only one step
to get the value, and previous testing showed this approach was even JIT - efficient.
> However, running the CasCopier test with and without JCas cover classes showed a large
slow-down for the JCas case.  Eventually, the evidence seemed to suggest some kind of memory
cache loading issue, perhaps the instruction cache, since each getter / setter (with JCas)
was running a different bit of code, whereas the non-JCas was running common code.
> Based on this observation, change the impl to simplify things by always using the array
of ints / refs approach to storing data, and change the JCas versions to reference that storage.
 As part of this, code the offsets in the JCas class as static final int values computed when
the class is loaded.   This imposes a restriction in the use case where, under a single class
loader, multiple type systems and one set of JCas classes are being used.  Add appropriate
checks to insure that the static final offset values remain correct when multiple type systems
are being used.  Also add checks to insure the JCas type hierarchy is consistent with the
UIMA Type system hierarchy, and that the range in the JCas getters is consistent with the
UIMA type system range for each feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message