lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Shabino (JIRA)" <>
Subject [jira] [Created] (SOLR-8688) Concurrent[LRU|LFU]Cache should clear() upon destroy() to reduce GC stress
Date Wed, 17 Feb 2016 20:32:18 GMT
Steve Shabino created SOLR-8688:

             Summary: Concurrent[LRU|LFU]Cache should clear() upon destroy() to reduce GC
                 Key: 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):

I would be happy to prepare patches for either of these schemes.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message