spring-framework

Spring Framework

Brian Clozel 6ec264252b Ensure consistent value count in ConcurrentReferenceHashMap#Segment Prior to this commit, the `ConcurrentReferenceHashMap#Segment` would recalculate its element count during the restructure phase by subtracting the number of polled elements from the queue to the current count. Later, the newly restructured `references` array would only contain references that 1) are not in the set of elements to purge and 2) that hold a non-null value. The issues with this approach are multiple. The newly calculated count is only an estimate, as some situations can make it invalid, even temporarily. * since we initially collected all elements to be purged from the queue, the GC might have collected new values. This means that we might filter out more references that we initially intended to * because the restructure operation re-creates new references for all elements in the original array, we might later get references from the queue that are not in the array anymore. This could lead to "duplicate" removals for the same value Because several methods in the Segment class have special no-op behavior when `count == 0`, an invalid count can lead to keys appearing missing when they are actually still present. In some scenarios, this can decrease the performance of the cache since values need to be recalculated. This commit fixes this inconsistency count issue by first using an estimate in order to decide whether the array needs a resize and then by counting the actual numbers of elements inserted in the restructured array as the new count. Fixes gh-31373	2 years ago
..
src	Ensure consistent value count in ConcurrentReferenceHashMap#Segment	2 years ago
spring-core.gradle	Give spring-core access to org.jboss.vfs for VfsUtils support on WildFly	3 years ago

Brian Clozel 6ec264252b Ensure consistent value count in ConcurrentReferenceHashMap#Segment

Prior to this commit, the `ConcurrentReferenceHashMap#Segment` would
recalculate its element count during the restructure phase by
subtracting the number of polled elements from the queue to the current
count.
Later, the newly restructured `references` array would only contain
references that 1) are not in the set of elements to purge and
2) that hold a non-null value.

The issues with this approach are multiple. The newly calculated count
is only an estimate, as some situations can make it invalid, even
temporarily.

* since we initially collected all elements to be purged from the queue,
  the GC might have collected new values. This means that we might
  filter out more references that we initially intended to

* because the restructure operation re-creates new references for all
  elements in the original array, we might later get references from the
  queue that are not in the array anymore. This could lead to
  "duplicate" removals for the same value

Because several methods in the Segment class have special no-op behavior
when `count == 0`, an invalid count can lead to keys appearing missing
when they are actually still present. In some scenarios, this can
decrease the performance of the cache since values need to be
recalculated.

This commit fixes this inconsistency count issue by first using an
estimate in order to decide whether the array needs a resize and then by
counting the actual numbers of elements inserted in the restructured
array as the new count.

Fixes gh-31373

2 years ago

src

Ensure consistent value count in ConcurrentReferenceHashMap#Segment

2 years ago

spring-core.gradle

Give spring-core access to org.jboss.vfs for VfsUtils support on WildFly

3 years ago