All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jakub Narębski" <jnareb@gmail.com>
To: Abhishek Kumar <abhishekkumar8222@gmail.com>, git@vger.kernel.org
Cc: "Jakub Narębski" <jnareb@gmail.com>, "Derrick Stolee" <stolee@gmail.com>
Subject: Re: [PATCH v3 1/4] alloc: introduce parsed_commits_count
Date: Sat, 13 Jun 2020 01:16:51 +0200	[thread overview]
Message-ID: <8b0facef-c85d-c25c-d49d-2bc1a3836e77@gmail.com> (raw)
In-Reply-To: <20200612184014.1226972-2-abhishekkumar8222@gmail.com>

On 12.06.2020, Abhishek Kumar wrote:

> Commit slab relies on uniqueness of commit->index to access data. As
> submodules are repositories on their own, alloc_commit_index() (which
> depends on repository->parsed_objects->commit_count) no longer
> returns unique values.
> 
> This would break tests once we move `generation` and `graph_pos` into a
> commit slab, as commits of supermodule and submodule can have the same
> index but must have different graph positions.

First, commits of supermodule and of submodule are in different graphs,
so I don't see why they have to be in the same serialized commit-graph
file.

Second, Git stores many different types of information on slab already.
How comes that we have not had any problems till now?  

There is contains_cache, commit_seen, indegree_slab, author_date_slab,
commit_base, commit_pos, bloom_filter_slab, buffer_slab, commit_rev_name,
commit_names, commit_name_slab, saved_parents, blame_suspects,
commit_todo_item.

> 
> Let's introduce a counter variable, `parsed_commits_count` to keep track
> of parsed commits so far.

All right, thought it might be worth mentioning that it is a global
variable, or rather a static variable in a function.

> 
> 
> Signed-off-by: Abhishek Kumar <abhishekkumar8222@gmail.com>
> ---
> 
> CI Build for the failing tests:
> https://travis-ci.com/github/abhishekkumar2718/git/jobs/345413840

The failed tests are, from what I see:
- t4060-diff-submodule-option-diff-format.sh
- t4041-diff-submodule-option.sh
- t4059-diff-submodule-not-initialized.sh


> 
>   alloc.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/alloc.c b/alloc.c
> index 1c64c4dd16..29f0e3aa80 100644
> --- a/alloc.c
> +++ b/alloc.c
> @@ -101,7 +101,9 @@ void *alloc_object_node(struct repository *r)
>   
>   static unsigned int alloc_commit_index(struct repository *r)
>   {
> -	return r->parsed_objects->commit_count++;
> +	static unsigned int parsed_commits_count = 0;
> +	r->parsed_objects->commit_count++;

Do we use r->parsed_objects->commit_count anywhere?

> +	return parsed_commits_count++;

Does it matter that it is not thread safe, because it is not atomic?
Shouldn't it be

  +	static _Atomic unsigned int parsed_commits_count = 0;

or

  +	static _Atomic unsigned int parsed_commits_count = ATOMIC_VAR_INIT(0);

(If it is allowed).

>   }
>   
>   void init_commit_node(struct repository *r, struct commit *c)
> 


  parent reply	other threads:[~2020-06-12 23:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12 18:40 [GSoC Patch v3 0/4] Move generation, graph_pos to a slab Abhishek Kumar
2020-06-12 18:40 ` [PATCH v3 1/4] alloc: introduce parsed_commits_count Abhishek Kumar
2020-06-12 20:08   ` Junio C Hamano
2020-06-12 22:00     ` Junio C Hamano
2020-06-12 22:20       ` Junio C Hamano
2020-06-12 22:52   ` Junio C Hamano
2020-06-13 18:57     ` Abhishek Kumar
2020-06-12 23:16   ` Jakub Narębski [this message]
2020-06-12 18:40 ` [PATCH v3 2/4] commit-graph: introduce commit_graph_data_slab Abhishek Kumar
2020-06-13  6:53   ` SZEDER Gábor
2020-06-17  9:18     ` Abhishek Kumar
2020-06-12 18:40 ` [PATCH v3 3/4] commit: move members graph_pos, generation to a slab Abhishek Kumar
2020-06-12 18:40 ` [PATCH v3 4/4] commit-graph: minimize commit_graph_data_slab access Abhishek Kumar
2020-06-12 21:26 ` [GSoC Patch v3 0/4] Move generation, graph_pos to a slab Jakub Narębski
  -- strict thread matches above, loose matches on Subject: below --
2020-06-14  6:09 [PATCH v3 1/4] alloc: introduce parsed_commits_count Abhishek Kumar

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=8b0facef-c85d-c25c-d49d-2bc1a3836e77@gmail.com \
    --to=jnareb@gmail.com \
    --cc=abhishekkumar8222@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=stolee@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.