Steve Shabino created SOLR-8688:
-----------------------------------
Summary: Concurrent[LRU|LFU]Cache should clear() upon destroy() to
reduce GC stress
Key: SOLR-8688
URL: https://issues.apache.org/jira/browse/SOLR-8688
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: master
Reporter: Steve Shabino
Priority: Minor
When a SolrIndexSearcher is close()'d, it calls close() on all of its caches.
FastLRUCache and LFUCache then call Concurrent[LRU|LFU]Cache's destroy(). The
destroy method stops the clean-up thread if present, but it does not evict all
cache entries - no longer of any value to a destroyed cache.
Because Concurrent[LRU|LFU]Cache has a finalize() method, it and all objects
referenced by it, even indirectly, may not be GC'ed until the JVM performs a
major GC and the finalization thread runs.
Calling clear() on the underlying ConcurrentHashMap after stopping the clean-up
thread will free cache entries (Several gigs worth as we're currently
configured in production) for GC, independent of the JVM's finalization process.
Alternatively, uses of the finalize() method could be replaced with a clean-up
scheme which makes use of PhantomReferences. There are a few other uses of
finalize() in Solr which also could benefit from this. An example project (that
I've only perused briefly): https://github.com/claudemartin/java-cleanup
I would be happy to prepare patches for either of these schemes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
