[
https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16579964#comment-16579964
]
Michael Braun commented on LUCENE-8434:
---------------------------------------
[~thetaphi] I checked and OmitStackTraceInFastThrow only applies to the
'standard' runtime exceptions that might be encountered, like AIOOBE, NPE, etc
(see
https://github.com/JetBrains/jdk8u_hotspot/blob/435f973f98771edfa2126d5e6b6dea9bbf272e86/src/share/vm/opto/graphKit.cpp#L557)
so it does not do anything for types outside of these.
That said this didn't make much of a difference in benchmarks so this ticket
can be closed.
> Use shared instance of CollectionTerminatedException
> ----------------------------------------------------
>
> Key: LUCENE-8434
> URL: https://issues.apache.org/jira/browse/LUCENE-8434
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael Braun
> Priority: Minor
>
> Creating exceptions and filling in the stack is expensive (see SOLR-11242 and
> SOLR-11314 for two such examples). CollectionTerminatedException is used as a
> signaling mechanism - there are zero instances in code that actually log that
> it occurred or make use of anything other than the fact that it occurred
> (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions
> really should be for something exceptional - the use of
> CollectionTerminatedException is in place of polluting return values with
> this condition and is just used as a signal to callers.
> Because CollectionTerminatedException is never inspected directly and is
> effectively a different return condition, it doesn't make as much sense to
> generate new Exceptions with fresh stack traces every time - either change
> the signatures or share the object.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
