[ 
https://issues.apache.org/jira/browse/LUCENE-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14942337#comment-14942337
 ] 

Paul Elschot commented on LUCENE-6821:
--------------------------------------

There is another Term constructor call that is a clone at PhraseQuery line 104, 
this could also be removed.

bq. Won't this change have the prospect of increasing the amount of GC due to 
all these extra objects?

The patch also removes some calls to BytesRef.deepCopyOf, so I'm not sure here.

bq. have an alternative constructor that doesn't clone

This has bitten a few people at least, including me, and I'd rather have it 
work correctly in the case when the BytesRef comes directly from a TermsEnum.

The Term(String field, String text) constructor makes a new BytesRef anyway.

bq. so that users like Solr can exploit the fact that their code won't be 
making any further use of the input term?

There are at least a few places in Solr with a BytesRef.deepCopyOf result 
directly passed to a Term constructor, for example in FacetField and 
SolrIndexSearcher. There this call could be removed also.
I'm not familiar with Solr code, so in case there is another impact there, 
please holler.



> TermQuery's constructors should clone the incoming term
> -------------------------------------------------------
>
>                 Key: LUCENE-6821
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6821
>             Project: Lucene - Core
>          Issue Type: Task
>            Reporter: Adrien Grand
>            Priority: Minor
>         Attachments: LUCENE-6821.patch
>
>
> This is a follow-up of LUCENE-6435: the bug stems from the fact that you can 
> build term queries out of shared BytesRef objects (such as the ones returned 
> by TermsEnum.next), which is a bit trappy. If TermQuery's constructors would 
> clone the incoming term, we wouldn't have this trap.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to