Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: tarantool-patches@freelists.org, imeevma@tarantool.org
Subject: [tarantool-patches] Re: [PATCH v2 1/2] box: create bigrefs for tuples
Date: Fri, 8 Jun 2018 00:24:19 +0300	[thread overview]
Message-ID: <ad4a1696-b4a1-16bc-f256-b3dd65abbc82@tarantool.org> (raw)
In-Reply-To: <6bfce1d3b6f797a6ebf3e56f81fad4181e855453.1528388742.git.imeevma@gmail.com>

Hello. Thanks for the patch! I have pushed some minor fixes. Look at
them, squash. See the rest 3 comments below.

> diff --git a/test/unit/tuple_bigref.c b/test/unit/tuple_bigref.c
> new file mode 100644
> index 0000000..fd166fd
> --- /dev/null
> +++ b/test/unit/tuple_bigref.c
> @@ -0,0 +1,156 @@
> +#include "vy_iterators_helper.h"
> +#include "memory.h"
> +#include "fiber.h"
> +#include "unit.h"
> +#include <msgpuck.h>
> +#include "trivia/util.h"
> +
> +enum
> +{
> +	BIGREF_DIFF = 10,
> +	BIGREF_COUNT = 100003,

1. Please, reduce the count to 70k for example. There is no
difference 100k or 70k for bigref list, but the test will be
faster.

> +	BIGREF_CAPACITY = 107,
> +};
> +
> +/**
> + * This test checks that indexes are given as intended.

2. Actually this test works exactly like the first one. See the
comments below.

> + */
> +static int
> +test_bigrefs_3()
> +{
> +	struct tuple **tuples = (struct tuple **) malloc(BIGREF_CAPACITY *
> +							 sizeof(*tuples));
> +	for(int i = 0; i < BIGREF_CAPACITY; ++i) {
> +		tuples[i] = create_tuple();
> +		tuple_ref(tuples[i]);
> +	}
> +	for(int i = 0; i < BIGREF_CAPACITY; ++i) {
> +		assert(tuples[i]->refs == 1);
> +		for(int j = 1; j < BIGREF_COUNT; ++j)
> +			box_tuple_ref(tuples[i]);
> +		assert(tuples[i]->is_bigref);
> +		if(i % BIGREF_DIFF == 0) {
> +			for(int j = 1; j < BIGREF_COUNT; ++j)
> +				box_tuple_unref(tuples[i]);
> +		}

3. Here when i % BIGREF_DIFF, you had added the tuple to bigref list,
and then have deleted it immediately. So the list has no gaps and works
exactly like in the first test.

Please, rework this test to test a list with gaps. You should fill it,
then remove some of tuples, for example, each BIGREF_DIFF, and check,
that other tuples are not destroyed. And that new tuples occupy the
gaps.

And please, use gcov to check coverage of tuple bigrefs. I have run
gcov, and saw this:

         -:  362:static inline void
         -:  363:bigref_list_delete_index(uint16_t index)
         -:  364:{
       648:  365:	bigref_list.refs[index] = 0;
       648:  366:	if (--bigref_list.size == 0) {
        15:  367:		bigref_list_reset();
        15:  368:		return;
         -:  369:	}
         -:  370:	/* Drop the 'take' hint. */
       633:  371:	bigref_list.hint_index_to_take = 0;
      1263:  372:	if (bigref_list.capacity == BIGREF_MIN_CAPACITY ||
       630:  373:	    bigref_list.size > bigref_list.capacity / BIGREF_FACTOR)
       249:  374:		return;
         -:  375:
       384:  376:	uint16_t top_index = bigref_list.hint_index_to_free;
      1086:  377:	while (bigref_list.refs[top_index] == 0)
       159:  378:		top_index--;
       384:  379:	bigref_list.hint_index_to_free = top_index;
         -:  380:
       384:  381:	uint16_t needed_capacity = top_index + 1;
       384:  382:	if (needed_capacity < BIGREF_MIN_CAPACITY)
     #####:  383:		needed_capacity = BIGREF_MIN_CAPACITY;
       384:  384:	if (needed_capacity > bigref_list.capacity / BIGREF_FACTOR)
       384:  385:		return;
         -:  386:	/* Round up capacity to the next highest power of 2. */
         -:  387:	assert(sizeof(needed_capacity) == sizeof(uint16_t));
     #####:  388:	needed_capacity--;
     #####:  389:	needed_capacity |= needed_capacity >> 1;
     #####:  390:	needed_capacity |= needed_capacity >> 2;
     #####:  391:	needed_capacity |= needed_capacity >> 4;
     #####:  392:	needed_capacity |= needed_capacity >> 8;
     #####:  393:	assert(needed_capacity < UINT16_MAX);
     #####:  394:	needed_capacity++;
     #####:  395:	uint32_t *refs =
     #####:  396:		(uint32_t *) realloc(bigref_list.refs, needed_capacity *
         -:  397:				     sizeof(*bigref_list.refs));
     #####:  398:	if (refs == NULL) {
     #####:  399:		panic("failed to reallocate %zu bytes: Cannot allocate "\
         -:  400:		      "memory.", needed_capacity * sizeof(*bigref_list.refs));
         -:  401:	}
     #####:  402:	bigref_list.refs = refs;
     #####:  403:	bigref_list.capacity = needed_capacity;
       648:  404:}


##### means this line had never been executed. You should write such a test, that
will cover these lines.

To use gcov you can build Tarantool with ENABLE_GCOV:

     cmake . -DENABLE_GCOV=1
     make -j

Then you run the test:

     ./test/unit/tuple_bigref.test

Then you convert .gcda/.gcno files to .gcov files:

     gcov src/box/tuple.c -o src/box/CMakeFiles/tuple.dir/tuple.c.gcno

Now tuple.c.gcov stores the coverage info.
These commands work on Mac. Maybe on Linux it differs. If cmake ENABLE_GCOV
does not work, then try this:

     @@ -4,10 +4,7 @@ set(ENABLE_GCOV_DEFAULT OFF)
      option(ENABLE_GCOV "Enable integration with gcov, a code coverage program" ${ENABLE_GCOV_DEFAULT})
  
      if (ENABLE_GCOV)
     -    if (NOT HAVE_GCOV)
     -    message (FATAL_ERROR
     -         "ENABLE_GCOV option requested but gcov library is not found")
     -    endif()

and run cmake again.

  reply	other threads:[~2018-06-07 21:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1528388742.git.imeevma@gmail.com>
2018-06-07 16:28 ` [tarantool-patches] " imeevma
2018-06-07 21:24   ` Vladislav Shpilevoy [this message]
2018-06-08 10:46     ` [tarantool-patches] " Imeev Mergen
2018-06-08 12:03       ` Vladislav Shpilevoy
2018-06-09 11:31         ` Vladimir Davydov
2018-06-07 16:34 ` [tarantool-patches] [PATCH v2 2/2] tuple: introduce bigref hints imeevma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad4a1696-b4a1-16bc-f256-b3dd65abbc82@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=imeevma@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH v2 1/2] box: create bigrefs for tuples' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox