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
prev parent 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).