[
https://issues.apache.org/jira/browse/UIMA-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor updated UIMA-4663:
---------------------------------
Description:
Switch the storage model for Feature Structures to align with Java's Object
Model, while preserving backwards compatibility.
This allows garbage collection of Feature Structures.
There is likely a performance benefit by having the data in one place only,
with no conversions needed between the Java world and the data-on-the int-heap
world of V2.
JCasGen capability (optional) will create Java fields representing the Feature
values; getters will become simple get operations. Setters are more complex
due to the need to support things like index corruption checking and journaling
(when using Delta Cas operations).
Types without JCasGen'd classes will use generic Java class representation and
store their features in a couple of local collections.
Mixing of these two approaches is also possible; e.g., the built-in type
Annotation defines begin / end fields, which are represented as Java fields.
Additional features may be represented by subtypes having no JCasGen'd class
definition, and those fields would be saved in the generic local collections.
The goal is to support fast/efficient access both with and without JCas-gen'd
classes.
was:
Switch the storage model for Feature Structures to align with Java's Object
Model, while preserving backwards compatibility.
This allows garbage collection of Feature Structures.
There is likely a performance benefit by having the data in one place only,
with no conversions needed between the Java world and the data-on-the int-heap
world of V2.
> UV3 Represent Feature Structures as Java Objects
> ------------------------------------------------
>
> Key: UIMA-4663
> URL: https://issues.apache.org/jira/browse/UIMA-4663
> Project: UIMA
> Issue Type: Story
> Components: Core Java Framework
> Reporter: Marshall Schor
>
> Switch the storage model for Feature Structures to align with Java's Object
> Model, while preserving backwards compatibility.
> This allows garbage collection of Feature Structures.
> There is likely a performance benefit by having the data in one place only,
> with no conversions needed between the Java world and the data-on-the
> int-heap world of V2.
> JCasGen capability (optional) will create Java fields representing the
> Feature values; getters will become simple get operations. Setters are more
> complex due to the need to support things like index corruption checking and
> journaling (when using Delta Cas operations).
> Types without JCasGen'd classes will use generic Java class representation
> and store their features in a couple of local collections.
> Mixing of these two approaches is also possible; e.g., the built-in type
> Annotation defines begin / end fields, which are represented as Java fields.
> Additional features may be represented by subtypes having no JCasGen'd class
> definition, and those fields would be saved in the generic local collections.
> The goal is to support fast/efficient access both with and without JCas-gen'd
> classes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
