[jira] [Created] (UIMA-4824) uv3 change storage model to always use int and ref arrays

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

Marshall Schor created UIMA-4824:
------------------------------------

             Summary: 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.



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