good point. And a reminder to think about this more carefully. -Marshall
On 5/17/2019 4:11 AM, Richard Eckart de Castilho (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/UIMA-6043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841991#comment-16841991 > ] > > Richard Eckart de Castilho commented on UIMA-6043: > -------------------------------------------------- > > I read the comment in the documentation stating that a switch from low-level > CAS methods to JCas is recommended to avoid pinning. > > Just taking a note here again that I personally find the pinning quite useful > because it saves me from having to manage FS IDs and having to "pollute" > every feature structure with such an ID. The use-case is an annotation editor > where it is important for the editor to be able to uniquely identify FSes > even across the CAS being persisted and reloaded. Being able to use the ID > mechanism provided by UIMA in combination with the SERIALIZED_TSI format is > very convenient here. > >> uv3 add -D flag to report on feature structure pinning >> ------------------------------------------------------ >> >> Key: UIMA-6043 >> URL: https://issues.apache.org/jira/browse/UIMA-6043 >> Project: UIMA >> Issue Type: Improvement >> Components: Core Java Framework >> Affects Versions: 3.0.2SDK >> Reporter: Marshall Schor >> Assignee: Marshall Schor >> Priority: Minor >> Fix For: 3.0.3SDK >> >> >> When migrating to UIMA v3, code might inadvertently cause some feature >> structures (FSs) to be pinned in memory, typically by producing some int >> value that could be used to retrieve the FS. If pinned, a FS cannot be >> garbage collected. >> Turning on this -D flag will produce a report of where code is pinning FSs. > > > -- > This message was sent by Atlassian JIRA > (v7.6.3#76005) >
