tarantool / tarantool / 12392276554
87%
master: 87%

LAST BUILD BRANCH: ci-backport-on-comment
DEFAULT BRANCH: master
Ran
Jobs 1
Files 514
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 87.266% (-0.002%) from 87.268%
12392276554

push

github

locker 
small: bump version

A long time ago the it's been found that in some circumstances the
RTREE index could fail to rollback because of OOM. This is the case
because removal of a key from such an index can sometimes lead to
allocation of new blocks that could fail. So, in order to guarantee
a successful rollback of an insertion into the index, the memtx
engine extent reservation machinery had been introduced (see the
issue #727).

But some time ago it's beed found out that the reservation of memory
prior to insertion can be not enough to guarantee a successful roll
back of the statements, so it's been decided to use a regular malloc
for failed allocations performed during rollback (see #10551). This
also fixed the RTREE issue for which the extent reservation had been
introduced in the first place.

But this functionality allows to simplify code of data structures,
such as BPS tree, so that we can reserve the max amount of extents
that could be required to perform an operation and, if reservation
succeeds, be sure that we're safe from any kind of OOM up until we
have finished the operation.

But it's only known to specific data structures which amount of memory
will be required for them to perform their operations, and all current
memtx structures (BPS tree, light hash, rtree, bitset) use matras to
deal with memory allocations, so it would be nice to make them able to
reserve exactly as much extents as they need themselves instead of
reserving max sane amount of ones as it's done now (see the constants:
`RESERVE_EXTENTS_BEFORE_REPLACE` and `RESERVE_EXTENTS_BEFORE_DELETE`).

The problem is that if we reserve extents in each matras instance we
will possibly be wasting a lot of memory in each index, so it would
be much better to share the reserved extents as it's done in the memtx
engine now.

So, in order to allow indexes reserve memoy for themselves and share
the reserved memory amoug all indexes, let's introduce a new entity:
`matras_allocator`.

The ent... (continued)

68612 of 121880 branches covered (56.29%)

26 of 27 new or added lines in 9 files covered. (96.3%)

40 existing lines in 20 files now uncovered.

101229 of 116001 relevant lines covered (87.27%)

2659691.79 hits per line

New Missed Lines in Diff

Lines Coverage ∆ File
1
96.32
 0.01% src/box/vy_mem.c

Uncovered Existing Lines

Lines Coverage ∆ File
1
65.97
 1.53% src/lib/core/fio.c
1
95.89
 -0.05% src/box/iproto.cc
1
87.5
 -1.59% src/box/xlog.h
1
85.48
 -1.61% src/box/lua/ctl.c
1
97.4
 -0.06% src/lib/salad/bps_tree.h
1
72.77
 -0.25% src/main.cc
1
95.74
 -0.53% src/box/vy_range.c
1
91.45
 0.0% src/lib/swim/swim.c
2
86.27
 -0.42% src/box/vy_stmt.c
2
95.45
 -4.55% src/lib/json/json.h
2
87.72
 0.12% src/box/vy_run.c
2
95.05
 -0.62% src/box/raft.c
2
92.81
 -1.44% src/box/vy_point_lookup.c
2
96.15
 -3.85% src/lib/core/iostream.h
2
90.92
 0.03% src/box/box.cc
2
92.07
 0.0% src/box/vinyl.c
3
94.23
 -0.61% src/box/xrow_update_field.c
4
81.82
 -12.12% src/lua/minifio.c
4
90.7
 -0.3% src/box/applier.cc
5
94.95
 0.48% src/lib/small/small/matras.c
Jobs
ID Job ID Ran Files Coverage
1 12392276554.1 514
87.27
 GitHub Action Run
Source Files on build 12392276554