git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Eric Wong <e@80x24.org>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH v3] delta-islands: free island_marks and bitmaps
Date: Sat, 4 Feb 2023 06:14:55 -0500	[thread overview]
Message-ID: <Y94+L/mhBnnbi+0k@coredump.intra.peff.net> (raw)
In-Reply-To: <20230203234430.M553381@dcvr>

On Fri, Feb 03, 2023 at 11:44:30PM +0000, Eric Wong wrote:

> >  	/* If we aren't using islands, assume everything goes together. */
> > -	if (!island_marks)
> > +	if (!using_island_marks)
> >  		return 1;
> 
> I much prefer to rely on invalid pointers than extra flags since
> having multiple sources of truth confuses me[1].

That's kind of my point, though. It's not multiple sources of truth, but
rather there are two bits "did we ask to use islands" and "is
island_marks still valid". You are shoving both bits into the same
variable by using a special sentinel pointer.

> > And of course that would also be a tiny step in the right direction if
> > the delta islands API learned to use a struct (this would be the same
> > spot where we'd say "we're done with islands; free the struct").
> 
> I do wonder about performance on register-starved systems,
> though, especially if stuff like island_delta_cmp gets called
> frequently.  I already have enough performance problems atm :<

Calling in_same_island() is pretty heavy-weight (it's multiple hash
lookups, and then an arbitrary-length bit-string comparison). I'd be
shocked if replacing a global with a struct pointer is even measurable.

> [1] to go farther, I might even eliminate `int use_delta_islands' as
>     a global from builtin/pack-objects.c and just have that become a
>     `struct delta_islands_foo *' or something.  But I have more
>     pressing performance problems to figure out :<

Right, that's along the same lines I was thinking. But I don't blame
you for not tackling it. The upside is fairly minimal.

> +	/* detect use-after-free with a an address which is never valid: */
> +	island_marks = (void *)-1;

I still hate how magical this line is, but I don't that it's worth
arguing about more.

-Peff

      reply	other threads:[~2023-02-04 11:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-02  1:03 [PATCH] delta-islands: free island_marks and bitmaps Eric Wong
2023-02-02  1:45 ` Ævar Arnfjörð Bjarmason
2023-02-02  9:42   ` [PATCH v2] " Eric Wong
2023-02-03 18:11     ` Jeff King
2023-02-03 23:44       ` [PATCH v3] " Eric Wong
2023-02-04 11:14         ` Jeff King [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=Y94+L/mhBnnbi+0k@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).