[jira] [Commented] (SOLR-14639) Improve concurrency of SlowCompositeReaderWrapper.terms

["Shalin Shekhar Mangar (Jira)" <ji...@apache.org>]

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

Shalin Shekhar Mangar commented on SOLR-14639:
----------------------------------------------

The problem is that ConcurrentHashMap.computeIfAbsent can be costly under contention. In JDK8, computeIfAbsent locks the node in which the key should be present regardless of whether the key exists or not [1]. This means that computeIfAbsent is always blocking as compared to get() which is a non-blocking operation. In JDK9, this was slightly ameliorated by adding a fast-return in case the key was found in the first node without entering a synchronization block. But if there is a hash collision and the key is not in the first node, then computeIfAbsent enters into a synchronization block on the node to find the key. For a cache, we can expect that the key will exist in most of the lookups so it makes sense to avoid the cost of entering a synchronized block for retrieval.

Doug Lea wrote on the concurrency mailing list [2]:
{code}
With the current implementation,
if you are implementing a cache, it may be better to code cache.get
to itself do a pre-screen, as in:
   V v = map.get(key);
   return (v != null) ? v : map.computeIfAbsent(key, function);

However, the exact benefit depends on access patterns.
For example, I reran your benchmark cases (urls below) on a
32way x86, and got throughputs (ops/sec) that are dramatically
better with pre-screen for the case of a single key,
but worse with your Zipf-distributed keys.
{code}

I would like to implement this method or switch to caffeine which has a non-blocking return in case the keys already exist [3].

[1] - https://concurrency-interest.altair.cs.oswego.narkive.com/0Jfe1waD/computeifabsent-optimized-for-missing-entries
[2] - http://cs.oswego.edu/pipermail/concurrency-interest/2014-December/013360.html
[3] - https://github.com/ben-manes/caffeine/wiki/Benchmarks

> Improve concurrency of SlowCompositeReaderWrapper.terms
> -------------------------------------------------------
>
>                 Key: SOLR-14639
>                 URL: https://issues.apache.org/jira/browse/SOLR-14639
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: search
>    Affects Versions: 8.4.1
>            Reporter: Shalin Shekhar Mangar
>            Priority: Major
>         Attachments: Screen Shot 2020-07-09 at 4.38.03 PM.png
>
>
> Under heavy query load, the ConcurrentHashMap.computeIfAbsent method inside the SlowCompositeReaderWrapper.terms(String) method blocks searcher threads (see attached screenshot of a java flight recording).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org