Description
Description
Change [1] introduced numberOfObjectsSinceBitmap to RepoStatistics.
This number contains the number ofobjects stored in pack files and as loose objects created since thelatest bitmap generation.
Change [2] fixed its calculation by stop counting as soon as the most recent bitmap is encountered.
However, I've identified a case where the way the "number of objects since bitmap" metric may be inaccurate or misleading when GC happens.
The Problem
When Garbage Collection (GC) occurs, the non-heads packfile can be written slightly later than the heads packfile. This small timing difference can lead to incorrect accounting of objects.
Observed Behavior
In my local environment, I noticed the following:
Heads Packfile (with bitmap)
-r--r--r--@ 1 syntonyze staff 230648 Mar 7 21:08 pack-315d970458e6b4abf8f4e76373f2c88fbc225ca3.pack
-r--r--r--@ 1 syntonyze staff 12216 Mar 7 21:08 pack-315d970458e6b4abf8f4e76373f2c88fbc225ca3.idx
-r--r--r--@ 1 syntonyze staff 4862 Mar 7 21:08 pack-315d970458e6b4abf8f4e76373f2c88fbc225ca3.bitmap
Non-Heads Packfile (without bitmap)
-r--r--r--@ 1 syntonyze staff 814553 Mar 7 21:08 pack-0c4e73bf93d64177b8233d007c3ea29cf95ab5f2.pack
-r--r--r--@ 1 syntonyze staff 62728 Mar 7 21:08 pack-0c4e73bf93d64177b8233d007c3ea29cf95ab5f2.idx
At first glance, both packfiles appear to have the same timestamp (Mar 7, 21:08). However, upon closer inspection, the modification times (mtime) show a slight difference at the nanosecond level:
pack-0c4e73bf93d64177b8233d007c3ea29cf95ab5f2.pack (without bitmap) -> mtime: 2025-03-07T19:48:37.366075759Z
pack.315d970458e6b4abf8f4e76373f2c88fbc225ca3.pack (with bitmap) -> mtime: 2025-03-07T19:48:37.254571758Z
Since the non-heads packfile was written slightly later, it gets counted in the “number of objects since bitmap” metric.
This means the metric never resets to zero and always includes all objects from the non-heads packfile.
However, since both packfiles are effectively created at the same time, this behavior leads to inaccurate results.
I believe the objects in the non-heads packfile should not contribute to the "number of objects since bitmap" metric, as they are part of the same GC cycle. This would provide a more accurate representation of newly added objects.
The proposed solution is to add an additional metric to only count for the number of objects since the bitmap creation that are either loose or belong to "heads" packfiles.
[1] https://eclipse.gerrithub.io/c/eclipse-jgit/jgit/+/1203398
[2] https://review.gerrithub.io/c/eclipse-jgit/jgit/+/1208601
Motivation
I believe the objects in the non-heads packfile should not contribute to the "number of objects since bitmap" metric, as they are part of the same GC cycle. This would provide a more accurate representation of newly added objects.
Alternatives considered
No response
Additional context
No response