[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
