Commit-Queue | +1 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
gab: Please take a look. Thanks.
Code-Review | +1 |
Owners-Override | +1 |
LGTM % comments; owners-override for side-effects
// ByteCount committed by the system.
The type of this method's return value didn't change to ByteCount? Should it or should we restore the old comment?
static uint64_t AmountOfVirtualMemory();
Why not this one as well? Follow-up? Seems there are more we should update in this file too (disk space bytes, VM bytes, etc.). Submit a go/code-health-rotation if too onerous?
constexpr int64_t kUpperBound2GB = 2 * 1024; // inclusive
convert as well? here and below?
static constexpr int64_t kMinTotalDiskSpace = 64 * 1024 * 1024;
Gabriel CharetteWas this supposed to be 4 GiB, instead of 4 MiB?
!! Let's add a "TODO(429140103): This was migrated as-is to 4MiB in ByteCount but the legacy code potentially intended 4GiB, needs investigation." ? And follow-up (i.e. I wouldn't do it in this migration-only CL)?
BruschettaInstallerTest() : fake_20gb_memory(20ULL * 1024 * 1024) {}
This constructor used to take MiB, was this incorrectly passing 20TiB? Potentially worth fixing separately if I'm reading correctly so the migration remains a no-op (and avoids a revert)?
uint64_t ram_kb) {
This was incorrectly named `_kb` but specifying MB (per ScopedAmountOfPhysicalMemoryOverride's constructor)?
Worth fixing the tests and specifying the change in the CL description assuming they pass?
// Using 1077 rather than 1024 because it helps ensure that devices with
Drive-by: wow, second place with this magic constant, I'm puzzled as to why exactly 1077, it's just slightly bigger than 105% of 1024.. 🤷🏼♂️
size_t NavigationTransitionConfig::ComputeCacheSizeInBytes() {
There's room to keep expanding on some of these methods. Of course, we need to stop at some point on each CL, should we keep a list of methods to refactor in follow-up CLs (for a code health rotation)?
constexpr base::ByteCount k65GB = base::MiB(66560);
constexpr base::ByteCount k33GB = base::MiB(33792);
constexpr base::ByteCount k17GB = base::MiB(17408);
These are actually precise base::GiB multiples of 1024
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
joenotcharles: I trust your code reviews a lot. Could you take a look at this large change before it's landed?
The type of this method's return value didn't change to ByteCount? Should it or should we restore the old comment?
Done
The type of this method's return value didn't change to ByteCount? Should it or should we restore the old comment?
It's probably due to an incorrect search+replace. We should change the function's return type, but not in this CL.
Why not this one as well? Follow-up? Seems there are more we should update in this file too (disk space bytes, VM bytes, etc.). Submit a go/code-health-rotation if too onerous?
We should update it, but I had to stop at some point to keep this CL small-ish. go/code-health-rotation is a good idea.
constexpr int64_t kUpperBound2GB = 2 * 1024; // inclusive
convert as well? here and below?
Done. Note that I used MiB instead of GiB in some places below, because ByteCount doesn't support multiplication by floating point number (I'm unsure whether it should, but we can discuss that separately).
static constexpr int64_t kMinTotalDiskSpace = 64 * 1024 * 1024;
Gabriel CharetteWas this supposed to be 4 GiB, instead of 4 MiB?
!! Let's add a "TODO(429140103): This was migrated as-is to 4MiB in ByteCount but the legacy code potentially intended 4GiB, needs investigation." ? And follow-up (i.e. I wouldn't do it in this migration-only CL)?
Done
BruschettaInstallerTest() : fake_20gb_memory(20ULL * 1024 * 1024) {}
This constructor used to take MiB, was this incorrectly passing 20TiB? Potentially worth fixing separately if I'm reading correctly so the migration remains a no-op (and avoids a revert)?
Ack, added a TODO and preserved the 20 TiB for this CL.
uint64_t ram_kb) {
This was incorrectly named `_kb` but specifying MB (per ScopedAmountOfPhysicalMemoryOverride's constructor)?
Worth fixing the tests and specifying the change in the CL description assuming they pass?
Yes, the value was in MiB despite the variable name suggesting that it was in KiB. Given the test names (high RAM, low RAM), I suspect that the intent was to use MiB... (tests don't pass if we use KiB), it's just the variable name that was incorrect.
size_t NavigationTransitionConfig::ComputeCacheSizeInBytes() {
There's room to keep expanding on some of these methods. Of course, we need to stop at some point on each CL, should we keep a list of methods to refactor in follow-up CLs (for a code health rotation)?
Yes, I'll submit a code health rotation proposal after my vacation. This CL is only intended to be a proof of concept, and I need to stop somewhere.
constexpr base::ByteCount k65GB = base::MiB(66560);
constexpr base::ByteCount k33GB = base::MiB(33792);
constexpr base::ByteCount k17GB = base::MiB(17408);
These are actually precise base::GiB multiples of 1024
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
Owners-Override | +1 |
constexpr int64_t kUpperBound2GB = 2 * 1024; // inclusive
Francois Pierre Dorayconvert as well? here and below?
Done. Note that I used MiB instead of GiB in some places below, because ByteCount doesn't support multiplication by floating point number (I'm unsure whether it should, but we can discuss that separately).
Agreed that maybe it should, okay to park that for later if it comes up again.
size_t NavigationTransitionConfig::ComputeCacheSizeInBytes() {
Francois Pierre DorayThere's room to keep expanding on some of these methods. Of course, we need to stop at some point on each CL, should we keep a list of methods to refactor in follow-up CLs (for a code health rotation)?
Yes, I'll submit a code health rotation proposal after my vacation. This CL is only intended to be a proof of concept, and I need to stop somewhere.
Right but I meant that we should keep track of methods where we stopped and should resume? I suspect the code-health-rotation will need multiple iterations of "fix a method, stop at some depth, make a list of follow-ups, repeat"?
In other words, if we don't make a list now, how do we find these candidates again in the future?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
constexpr base::ByteCount k8GB = base::MiB(8192);
Curious, why can't this be GiB(8)?
Code-Review | +1 |
constexpr ByteCount kUpperBound3GB = MiB(3.2 * 1024); // inclusive
ByteCount now has a templated `GiB` function, but it looks like `GiB(3.2)` would convert to an int first, so it's a footgun.
As a followup, how about splitting the ByteCount templates into one with `requires std::is_integral_v<T>` and one with `requires std::is_floating_point_v<T>` that uses `CheckedNumeric<double>(gib) * 1024 * 1024 * 1024` and then coerces the result to `int64_t`? Then this can change to `GiB(3.2)`.
constexpr ByteCount kUpperBound6GB = MiB(6.5 * 1024 - 1); // inclusive
Nit: should be `MiB(6.5 * 1024) - 1`, I think, in case `AmountOfPhysicalMemory()` ever returns incremements smaller than 1 MB.
return ByteCount(pages * page_size);
Nit: how about `ByteCount(pages) * page_size` which will CHECK on overflow?
return KiB(info.free + info.speculative);
Nit: `KiB(info.free) + KiB(info.speculative)` will CHECK on overflow.
return base::ByteCount(pages * page_size);
Nit: `ByteCount(pages) * page_size`?
return KiB(info.free + info.speculative);
Nit: `KiB(info.free) + KiB(info.speculative)`?
return ByteCount(pages * page_size);
Nit: `ByteCount(pages) * page_size`?
// `info.file_backed` is in kb, so multiply it by 1024 to get the amount of
Nit: this comment's not useful anymore.
total_bytes.InBytes());
Nit: I think you could just do one `.InBytes()` at the end of the calculation. Less back and forth and risk of overflow.
`((available_bytes + base::KiB(info.file_backed)) * 100 / total_bytes).InBytes()`
/*ram=*/base::MiB(8000)),
Nit: these could use comments that the original code used MB but said KB, needs investigation.
kMiracleParameterMemory512MB - base::MiB(1));
Nit: I think these should all be `- 1` since the measurement used to be in 1 MB granularity and now is in 1 byte, and it's testing 1 less than the boundary condition.
static_cast<double>(base::SysInfo::AmountOfPhysicalMemory().InBytes());
Nit: as a followup, how about adding `InBytesF` to ByteCount to avoid the cast?
const int free_memory = static_cast<int>(
Nit: putting this inline in the function call should avoid the cast. `SetCurrentFreeMemoryInKB(AmountOfEtc().InKb())`
constexpr base::ByteCount k8GB = base::MiB(8192);
Curious, why can't this be GiB(8)?
Nit: please use `GiB(8)`. :-)
constexpr ByteCount kUpperBound3GB = MiB(3.2 * 1024); // inclusive
ByteCount now has a templated `GiB` function, but it looks like `GiB(3.2)` would convert to an int first, so it's a footgun.
As a followup, how about splitting the ByteCount templates into one with `requires std::is_integral_v<T>` and one with `requires std::is_floating_point_v<T>` that uses `CheckedNumeric<double>(gib) * 1024 * 1024 * 1024` and then coerces the result to `int64_t`? Then this can change to `GiB(3.2)`.
Nice review Joe!
constexpr ByteCount kUpperBound3GB = MiB(3.2 * 1024); // inclusive
Thiabaud EngelbrechtByteCount now has a templated `GiB` function, but it looks like `GiB(3.2)` would convert to an int first, so it's a footgun.
As a followup, how about splitting the ByteCount templates into one with `requires std::is_integral_v<T>` and one with `requires std::is_floating_point_v<T>` that uses `CheckedNumeric<double>(gib) * 1024 * 1024 * 1024` and then coerces the result to `int64_t`? Then this can change to `GiB(3.2)`.
https://chromium-review.googlesource.com/c/chromium/src/+/6759641
+1 to Joe's suggestion for a floating point constructor to avoid explicit "1024" everywhere.
(I initially wasn't sure but the solution is quite clean with the template `requires` keyword 😊)
constexpr ByteCount kUpperBound3GB = MiB(3.2 * 1024); // inclusive
Thiabaud EngelbrechtByteCount now has a templated `GiB` function, but it looks like `GiB(3.2)` would convert to an int first, so it's a footgun.
As a followup, how about splitting the ByteCount templates into one with `requires std::is_integral_v<T>` and one with `requires std::is_floating_point_v<T>` that uses `CheckedNumeric<double>(gib) * 1024 * 1024 * 1024` and then coerces the result to `int64_t`? Then this can change to `GiB(3.2)`.
Gabriel Charettehttps://chromium-review.googlesource.com/c/chromium/src/+/6759641
+1 to Joe's suggestion for a floating point constructor to avoid explicit "1024" everywhere.
(I initially wasn't sure but the solution is quite clean with the template `requires` keyword 😊)
The floating point constructor is up for review in https://crrev.com/c/6764394.
static_cast<double>(base::SysInfo::AmountOfPhysicalMemory().InBytes());
Nit: as a followup, how about adding `InBytesF` to ByteCount to avoid the cast?
Added an InBytesF in https://crrev.com/c/6764394
constexpr ByteCount kUpperBound3GB = MiB(3.2 * 1024); // inclusive
Thiabaud EngelbrechtByteCount now has a templated `GiB` function, but it looks like `GiB(3.2)` would convert to an int first, so it's a footgun.
As a followup, how about splitting the ByteCount templates into one with `requires std::is_integral_v<T>` and one with `requires std::is_floating_point_v<T>` that uses `CheckedNumeric<double>(gib) * 1024 * 1024 * 1024` and then coerces the result to `int64_t`? Then this can change to `GiB(3.2)`.
Gabriel Charettehttps://chromium-review.googlesource.com/c/chromium/src/+/6759641
Joe Mason+1 to Joe's suggestion for a floating point constructor to avoid explicit "1024" everywhere.
(I initially wasn't sure but the solution is quite clean with the template `requires` keyword 😊)
The floating point constructor is up for review in https://crrev.com/c/6764394.
Done - Now using the floating point API
constexpr ByteCount kUpperBound6GB = MiB(6.5 * 1024 - 1); // inclusive
Nit: should be `MiB(6.5 * 1024) - 1`, I think, in case `AmountOfPhysicalMemory()` ever returns incremements smaller than 1 MB.
I prefer to preserve the existing code behavior.
Nit: how about `ByteCount(pages) * page_size` which will CHECK on overflow?
Done
Nit: `KiB(info.free) + KiB(info.speculative)` will CHECK on overflow.
Done
Nit: `ByteCount(pages) * page_size`?
Done
Nit: `KiB(info.free) + KiB(info.speculative)`?
Done
Nit: `ByteCount(pages) * page_size`?
Done
// `info.file_backed` is in kb, so multiply it by 1024 to get the amount of
Nit: this comment's not useful anymore.
Done
Nit: I think you could just do one `.InBytes()` at the end of the calculation. Less back and forth and risk of overflow.
`((available_bytes + base::KiB(info.file_backed)) * 100 / total_bytes).InBytes()`
It's weird to call InBytes() on the result of (bytes / bytes), no? Bytes cancel out and the resulting value of bytes / bytes is not in bytes?
Nit: these could use comments that the original code used MB but said KB, needs investigation.
Done
Nit: I think these should all be `- 1` since the measurement used to be in 1 MB granularity and now is in 1 byte, and it's testing 1 less than the boundary condition.
Done
size_t NavigationTransitionConfig::ComputeCacheSizeInBytes() {
Francois Pierre DorayThere's room to keep expanding on some of these methods. Of course, we need to stop at some point on each CL, should we keep a list of methods to refactor in follow-up CLs (for a code health rotation)?
Gabriel CharetteYes, I'll submit a code health rotation proposal after my vacation. This CL is only intended to be a proof of concept, and I need to stop somewhere.
Right but I meant that we should keep track of methods where we stopped and should resume? I suspect the code-health-rotation will need multiple iterations of "fix a method, stop at some depth, make a list of follow-ups, repeat"?
In other words, if we don't make a list now, how do we find these candidates again in the future?
Good point. I think that TODOs in code are the most effective way to track this. They can be updated whenever the need to convert to ByteCount change (e.g. in changes unrelated to the rotation) and they're easy to add as the code is modified. Added a comment here. Note that we can also use AI to identify methods that return bytes 😊
static_cast<double>(base::SysInfo::AmountOfPhysicalMemory().InBytes());
Joe MasonNit: as a followup, how about adding `InBytesF` to ByteCount to avoid the cast?
Added an InBytesF in https://crrev.com/c/6764394
Done
Nit: putting this inline in the function call should avoid the cast. `SetCurrentFreeMemoryInKB(AmountOfEtc().InKb())`
Done
Joe MasonCurious, why can't this be GiB(8)?
Nit: please use `GiB(8)`. :-)
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
gab: This CL was rebased and I lost review votes. Can you take another look an CR+1 and OO+1? Thanks.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
Owners-Override | +1 |
gab: This CL was rebased and I lost review votes. Can you take another look an CR+1 and OO+1? Thanks.
Code-Review | +1 |
Owners-Override | +1 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +2 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
18 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
Use base::ByteCount in base::SysInfo.
Use base::ByteCount as the return value of
SysInfo::AmountOfPhysicalMemory() and
SysInfo::AmountOfAvailablePhysicalMemory() and adjust call sites across
the codebase. Note that other methods in base::SysInfo could also return
base::Bytes, but they're not upgraded in this CL to avoid making it
bigger.
base::ByteCount is a class to make bytes manipulations type safe, easier
to read and less error-prone.
NO_IFTTT=Code style change in base/system/sys_info.cc, does not affect code behavior.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
LUCI Bisection has identified this change as the cause of a test failure. See the analysis: https://ci.chromium.org/ui/p/chromium/bisection/test-analysis/b/6525964558270464
Sample build with failed test: https://ci.chromium.org/b/8706605585641464801
Affected test(s):
[ninja://base:base_unittests/SysUtils.AmountOfPhysicalMemory](https://ci.chromium.org/ui/test/chromium/ninja:%2F%2Fbase:base_unittests%2FSysUtils.AmountOfPhysicalMemory?q=VHash%3A436bad0fdfd39741)
A revert for this change was not created because the builder that this CL broke is not watched by gardeners, therefore less important. You can consider revert this CL, fix forward or let builder owners resolve it themselves.
If this is a false positive, please report it at http://b.corp.google.com/createIssue?component=1199205&description=Analysis%3A+https%3A%2F%2Fci.chromium.org%2Fui%2Fp%2Fchromium%2Fbisection%2Ftest-analysis%2Fb%2F6525964558270464&format=PLAIN&priority=P3&title=Wrongly+blamed+https%3A%2F%2Fchromium-review.googlesource.com%2Fc%2Fchromium%2Fsrc%2F%2B%2F6698912&type=BUG
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |