cc: Give non-drawing layers that are rasterized a lower priority.

cc: Give non-drawing layers that are rasterized a lower priority.

Currently layers which don't draw but are rasterized have the same
priority as the drawing layers. This patch does a few things to make
sure the drawing layers have a higher priority.

1) In RasterTilePriorityQueue, prioritize tilings from drawing layers
over non-drawing layers.
2) In LayerTreeImpl, make sure to update tiles for all layers with
valid tile priorities. Currently we end up missing the
|raster_event_if_not_in_rsll| layers.
3) Make sure that the non-drawing layers don't block activation of
the pending tree.

BUG=724591
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2899403003
Cr-Commit-Position: refs/heads/master@{#475145}
Committed: https://chromium.googlesource.com/chromium/src/+/2fc1dbd022af829f80502a0babe6a259c69dad58

[Khushal, 2017-05-24 21:44:34]

Description was changed from

==========
cc: Give non-drawing layers that are rasterized a lower priority.

Currently layers which don't draw but are rasterized have the same
priority as the drawing layers. This patch does a few things to make
sure the drawing layers have a higher priority.

1) In RasterTilePriorityQueue, prioritize tilings from drawing layers
over non-drawing layers.
2) In LayerTreeImpl, make sure to update tiles for all layers with
valid tile priorities. Currently we end up missing the
|raster_event_if_not_in_rsll| layers.
3) Make sure that the non-drawing layers don't block activation of
the pending tree.

BUG=724591
==========

to

==========
cc: Give non-drawing layers that are rasterized a lower priority.

Currently layers which don't draw but are rasterized have the same
priority as the drawing layers. This patch does a few things to make
sure the drawing layers have a higher priority.

1) In RasterTilePriorityQueue, prioritize tilings from drawing layers
over non-drawing layers.
2) In LayerTreeImpl, make sure to update tiles for all layers with
valid tile priorities. Currently we end up missing the
|raster_event_if_not_in_rsll| layers.
3) Make sure that the non-drawing layers don't block activation of
the pending tree.

BUG=724591
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

[Khushal, 2017-05-24 21:48:03]

khushalsagar@chromium.org changed reviewers:
+ jaydasika@chromium.org, vmpstr@chromium.org, weiliangc@chromium.org

[Khushal, 2017-05-24 21:57:06]

https://codereview.chromium.org/2899403003/diff/20001/cc/layers/picture_layer...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/2899403003/diff/20001/cc/layers/picture_layer...
cc/layers/picture_layer_impl.cc:519: bool can_require_tiles_for_activation =
contributes_to_drawn_render_surface();
Should this be done for requiring tiles for draw as well? I'm guessing there
wouldn't be much impact in the renderer from that right now since we don't block
drawing on ReadyToDraw there.

[Khushal, 2017-05-24 22:17:43]

The CQ bit was checked by khushalsagar@chromium.org to run a CQ dry run

[jaydasika, 2017-05-24 22:17:55]

https://codereview.chromium.org/2899403003/diff/20001/cc/layers/layer_impl.h
File cc/layers/layer_impl.h (right):

https://codereview.chromium.org/2899403003/diff/20001/cc/layers/layer_impl.h#...
cc/layers/layer_impl.h:583: bool raster_even_if_not_in_rsll_ : 1;
nit : we don't have a rsll anymore. Maybe this should be
raster_even_if_not_drawn ?

[commit-bot: I haz the power, 2017-05-24 22:19:02]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-24 22:23:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-24 22:23:35]

Dry run: Try jobs failed on following builders:
  linux_trusty_blink_rel on master.tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/linux_trusty_blink_rel/b...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Khushal, 2017-05-25 02:51:48]

khushalsagar@chromium.org changed reviewers:
+ danakj@chromium.org
- vmpstr@chromium.org

[Khushal, 2017-05-25 02:51:48]

And tested. PTAL.

[Khushal, 2017-05-25 02:52:59]

https://codereview.chromium.org/2899403003/diff/20001/cc/layers/layer_impl.h
File cc/layers/layer_impl.h (right):

https://codereview.chromium.org/2899403003/diff/20001/cc/layers/layer_impl.h#...
cc/layers/layer_impl.h:583: bool raster_even_if_not_in_rsll_ : 1;
On 2017/05/24 22:17:55, jaydasika wrote:
> nit : we don't have a rsll anymore. Maybe this should be
> raster_even_if_not_drawn ?

Yeah, that's better. I'll change it.

[Khushal, 2017-05-25 07:05:34]

The CQ bit was checked by khushalsagar@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-25 07:06:01]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-25 07:39:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-25 07:39:33]

Dry run: Try jobs failed on following builders:
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[danakj, 2017-05-25 15:49:03]

https://codereview.chromium.org/2899403003/diff/80001/cc/layers/picture_layer...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/2899403003/diff/80001/cc/layers/picture_layer...
cc/layers/picture_layer_impl.cc:519: bool can_require_tiles_for_activation =
contributes_to_drawn_render_surface();
Is there a test for this?

https://codereview.chromium.org/2899403003/diff/80001/cc/layers/picture_layer...
cc/layers/picture_layer_impl.cc:520: can_require_tiles_for_activation &=
while i appreciate splitting an if of || and &&s apart, this still is a long if
of || and &&s. would it read better if you instead did

if (only_used && !RequiresHighRes && SmoothnessTakesPrio)
  can_require_tiles_for_activation = false;

?

Alternatively phrase it as things that enable it, and a veto, like

bool can_require =  ... the old stuff ...;
if (!contributes_to_drawn_render_surface())
  can_require = false;

?

Alteralternatively give a name for your brain to use for a subset, like

bool some_name = ... the old stuff ...;
bool can_require = some_name && contributes_to_drawn()

?

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/raster_tile_pr...
File cc/tiles/raster_tile_priority_queue_all.cc (right):

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/raster_tile_pr...
cc/tiles/raster_tile_priority_queue_all.cc:19: bool operator()(
Can you put a comment here explaining when this returns true/false? true means b
takes priority right?

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/tiling_set_ras...
File cc/tiles/tiling_set_raster_queue_all.h (right):

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/tiling_set_ras...
cc/tiles/tiling_set_raster_queue_all.h:26: bool is_non_drawing_layer);
How about is_drawing_layer() so we can't have !is_non_drawing_layer() making
double negatives?

https://codereview.chromium.org/2899403003/diff/80001/cc/trees/layer_tree_imp...
File cc/trees/layer_tree_impl.cc (right):

https://codereview.chromium.org/2899403003/diff/80001/cc/trees/layer_tree_imp...
cc/trees/layer_tree_impl.cc:1147: if (!layer->HasValidTilePriorities())
Is there a test for this?

[Khushal, 2017-05-25 22:43:23]

https://codereview.chromium.org/2899403003/diff/80001/cc/layers/picture_layer...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/2899403003/diff/80001/cc/layers/picture_layer...
cc/layers/picture_layer_impl.cc:519: bool can_require_tiles_for_activation =
contributes_to_drawn_render_surface();
On 2017/05/25 15:49:02, danakj wrote:
> Is there a test for this?

Done. UpdatedTilingsForNonDrawingLayers.

https://codereview.chromium.org/2899403003/diff/80001/cc/layers/picture_layer...
cc/layers/picture_layer_impl.cc:520: can_require_tiles_for_activation &=
On 2017/05/25 15:49:02, danakj wrote:
> while i appreciate splitting an if of || and &&s apart, this still is a long
if
> of || and &&s. would it read better if you instead did
> 
> if (only_used && !RequiresHighRes && SmoothnessTakesPrio)
>   can_require_tiles_for_activation = false;
> 
> ?
> 
> Alternatively phrase it as things that enable it, and a veto, like
> 
> bool can_require =  ... the old stuff ...;
> if (!contributes_to_drawn_render_surface())
>   can_require = false;
> 
> ?

I flipped this one. Seemed odd to evaluate the or conditions only to reset it
later. How's this?

> 
> Alteralternatively give a name for your brain to use for a subset, like
> 
> bool some_name = ... the old stuff ...;
> bool can_require = some_name && contributes_to_drawn()
> 
> ?

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/raster_tile_pr...
File cc/tiles/raster_tile_priority_queue_all.cc (right):

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/raster_tile_pr...
cc/tiles/raster_tile_priority_queue_all.cc:19: bool operator()(
On 2017/05/25 15:49:02, danakj wrote:
> Can you put a comment here explaining when this returns true/false? true means
b
> takes priority right?

Yup, this is true if a < b. The comment is already there at the beginning of the
function. You wanna move it up?

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/tiling_set_ras...
File cc/tiles/tiling_set_raster_queue_all.h (right):

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/tiling_set_ras...
cc/tiles/tiling_set_raster_queue_all.h:26: bool is_non_drawing_layer);
On 2017/05/25 15:49:02, danakj wrote:
> How about is_drawing_layer() so we can't have !is_non_drawing_layer() making
> double negatives?

Done.

https://codereview.chromium.org/2899403003/diff/80001/cc/trees/layer_tree_imp...
File cc/trees/layer_tree_impl.cc (right):

https://codereview.chromium.org/2899403003/diff/80001/cc/trees/layer_tree_imp...
cc/trees/layer_tree_impl.cc:1147: if (!layer->HasValidTilePriorities())
On 2017/05/25 15:49:02, danakj wrote:
> Is there a test for this?

Done. UpdatedTilingsForNonDrawingLayers.

[danakj, 2017-05-26 15:46:20]

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/raster_tile_pr...
File cc/tiles/raster_tile_priority_queue_all.cc (right):

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/raster_tile_pr...
cc/tiles/raster_tile_priority_queue_all.cc:19: bool operator()(
On 2017/05/25 22:43:22, Khushal wrote:
> On 2017/05/25 15:49:02, danakj wrote:
> > Can you put a comment here explaining when this returns true/false? true
means
> b
> > takes priority right?
> 
> Yup, this is true if a < b. The comment is already there at the beginning of
the
> function. You wanna move it up?

Oh that looks like its commenting on the first lines of the function, yes please
:)

https://codereview.chromium.org/2899403003/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl_unittest.cc (right):

https://codereview.chromium.org/2899403003/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:12433:
EXPECT_EQ(animated_transform_layer->tilings()->num_tilings(), 0u);
Can you add some comments explaining what these expectations are testing for,
and how they link back to the scenarios this patch is fixes?

Some expectations on the layers might be helpful to show (and verify) that they
are non-drawing and such?

[Khushal, 2017-05-26 18:09:21]

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/raster_tile_pr...
File cc/tiles/raster_tile_priority_queue_all.cc (right):

https://codereview.chromium.org/2899403003/diff/80001/cc/tiles/raster_tile_pr...
cc/tiles/raster_tile_priority_queue_all.cc:19: bool operator()(
On 2017/05/26 15:46:20, danakj wrote:
> On 2017/05/25 22:43:22, Khushal wrote:
> > On 2017/05/25 15:49:02, danakj wrote:
> > > Can you put a comment here explaining when this returns true/false? true
> means
> > b
> > > takes priority right?
> > 
> > Yup, this is true if a < b. The comment is already there at the beginning of
> the
> > function. You wanna move it up?
> 
> Oh that looks like its commenting on the first lines of the function, yes
please
> :)

Done.

https://codereview.chromium.org/2899403003/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl_unittest.cc (right):

https://codereview.chromium.org/2899403003/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:12433:
EXPECT_EQ(animated_transform_layer->tilings()->num_tilings(), 0u);
On 2017/05/26 15:46:20, danakj wrote:
> Can you add some comments explaining what these expectations are testing for,
> and how they link back to the scenarios this patch is fixes?
> 
> Some expectations on the layers might be helpful to show (and verify) that
they
> are non-drawing and such?

Done.

[danakj, 2017-05-26 19:14:33]

LGTM

https://codereview.chromium.org/2899403003/diff/140001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl_unittest.cc (right):

https://codereview.chromium.org/2899403003/diff/140001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:12445: // The layer is still not
drawn, bit it will be rasterized. Since the layer is
but it

[Khushal, 2017-05-26 19:19:20]

https://codereview.chromium.org/2899403003/diff/140001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl_unittest.cc (right):

https://codereview.chromium.org/2899403003/diff/140001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:12445: // The layer is still not
drawn, bit it will be rasterized. Since the layer is
On 2017/05/26 19:14:33, danakj wrote:
> but it

Done.

[Khushal, 2017-05-26 19:19:34]

The CQ bit was checked by khushalsagar@chromium.org

[Khushal, 2017-05-26 19:19:34]

The patchset sent to the CQ was uploaded after l-g-t-m from danakj@chromium.org
Link to the patchset: https://codereview.chromium.org/2899403003/#ps160001
(title: "type")

[commit-bot: I haz the power, 2017-05-26 19:20:31]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-26 19:28:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-26 19:28:36]

Try jobs failed on following builders:
  linux_trusty_blink_rel on master.tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/linux_trusty_blink_rel/b...)
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_headless_rel on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Khushal, 2017-05-26 19:38:20]

The CQ bit was checked by khushalsagar@chromium.org

[commit-bot: I haz the power, 2017-05-26 19:38:56]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-26 19:47:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-26 19:47:18]

Try jobs failed on following builders:
  linux_trusty_blink_rel on master.tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/linux_trusty_blink_rel/b...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Khushal, 2017-05-26 20:39:18]

The CQ bit was checked by khushalsagar@chromium.org

[commit-bot: I haz the power, 2017-05-26 20:40:09]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-26 21:48:19]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1495831158422900,
"parent_rev": "e1aa28915a28da266d406202a07112d44d6cc018", "commit_rev":
"2fc1dbd022af829f80502a0babe6a259c69dad58"}

[commit-bot: I haz the power, 2017-05-26 21:48:54]

Description was changed from

==========
cc: Give non-drawing layers that are rasterized a lower priority.

Currently layers which don't draw but are rasterized have the same
priority as the drawing layers. This patch does a few things to make
sure the drawing layers have a higher priority.

1) In RasterTilePriorityQueue, prioritize tilings from drawing layers
over non-drawing layers.
2) In LayerTreeImpl, make sure to update tiles for all layers with
valid tile priorities. Currently we end up missing the
|raster_event_if_not_in_rsll| layers.
3) Make sure that the non-drawing layers don't block activation of
the pending tree.

BUG=724591
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

to

==========
cc: Give non-drawing layers that are rasterized a lower priority.

Currently layers which don't draw but are rasterized have the same
priority as the drawing layers. This patch does a few things to make
sure the drawing layers have a higher priority.

1) In RasterTilePriorityQueue, prioritize tilings from drawing layers
over non-drawing layers.
2) In LayerTreeImpl, make sure to update tiles for all layers with
valid tile priorities. Currently we end up missing the
|raster_event_if_not_in_rsll| layers.
3) Make sure that the non-drawing layers don't block activation of
the pending tree.

BUG=724591
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2899403003
Cr-Commit-Position: refs/heads/master@{#475145}
Committed:
https://chromium.googlesource.com/chromium/src/+/2fc1dbd022af829f80502a0babe6...
==========

[commit-bot: I haz the power, 2017-05-26 21:48:55]

Committed patchset #9 (id:160001) as
https://chromium.googlesource.com/chromium/src/+/2fc1dbd022af829f80502a0babe6...

[vmpstr, 2017-05-30 20:02:43]

Can you update the eviction iterator with a corresponding change as well?