ben-manes / caffeine

93%

master: 99%

LAST BUILD ON BRANCH v2.8.2

branch: v2.8.2

CHANGE BRANCH

x

Reset

• v2.8.2
• master
• v1.0
• v1.0.1
• v1.1.0
• v1.2.0
• cache2k
• guava
• buffer
• v1.3.0
• v1.3.1
• gilga
• gil
• clockpro
• v1.3.2
• ben/issue30
• v1.3.3
• Gil
• ben/spacing
• v2.0.0
• v2.0.1
• v2.0.2
• v2.0.3
• v2.1.0
• async-loader
• v2.2.0
• v2.2.2
• v2.2.4
• orm
• v2.3.2
• testng
• juherr
• jctools
• v2.3.4
• solr
• expiring_map
• expiry
• v2.5.2
• travis
• v2.5.3
• v2.5.4
• v2.5.5
• 2.5.6
• v2.6.1
• gradient
• adaptive
• tmp
• v2.7.0
• v2.8.0
• penalties
• v2.8.1
• v2.8.3
• v2.8.4
• v2.8.5
• codeql
• memory
• v3.dev
• v2.dev
• 05a040c2478341bab8a58a02b3dc1fe14d626d72
• v3.0.5
• v3.0.6
• v3.1.0
• v3.1.1
• v3.1.2
• v3.1.4
• v3.1.5
• dependabot/gradle/com.gradle.common-custom-user-data-gradle-plugin-1.9
• v3.1.6
• dependabot/github_actions/codecov/codecov-action-3.1.3
• dependabot/github_actions/JetBrains/qodana-action-61b94e7e3a716dcb9e2030cfd79cd46149d56c26
• dependabot/github_actions/github/codeql-action-2.3.4
• dependabot/github_actions/JetBrains/qodana-action-2023.1.4
• dependabot/gradle/com.gradle.enterprise-3.14
• v3.1.7
• v3.1.8
• dependabot/gradle/de.thetaphi-forbiddenapis-3.6
• dependabot/gradle/pmd-7.0.0-rc4

Build # 2550

Build Type

push

travis-ci

Committed by ben-manes

Commit Message

Fixed race causing an incorrect removal cause (fixes #412)

This bug manifests due to an incorrectly optimized `Map.remove(key)`
implementation when there is no CacheWriter specified. If there is,
an alternative implementation is used which does not suffer from this
mistake. This change now uses that version in all cases.

The explicit removal and an eviction of the same entry can occur
concurrently. If the removal wins the race, it is responsible for
retiring the entry. However even after that entry is discarded, an
further evictions may be necessary to meet the bounding criteria
(e.g. weighted entries). Therefore the eviction thread eagerly
discards the entry from the policy's data structures so that it can
continue its evaluation. While the entry is synchronized in both
cases, the eviction thread could lose the removal but retire the
entry first. This lead to the removal seeing a dead entry and
miscommunicating the cause to the listener.

There is a modest performance difference in a microbenchmark because
of a slightly coarser locking. However most of the differences between
libraries is whether they decide to be linearizable or perform an
optimistic check to no-op if the entry is absent. The optimistic check
avoids locking but also can lead to a removal to not block waiting for
an in-flight computation to complete. While a valid choice, some users
have expressed a desire for removal to be pessimistic and is rare
enough that we follow their wishes.

Run Details

6107 of 6550 relevant lines covered (93.24%)

0.93 hits per line