[scudo] Reflect the allowed values for M_DECAY_TIME on Android #89114
Conversation
llvmbot
added
compiler-rt
compiler-rt:scudo
|
@llvm/pr-subscribers-compiler-rt-sanitizer Author: None (ChiaHungDuan) ChangesOn Android, this interval constraint was used to avoid increasing the memory pressure by a long interval. Now the memory footprint is managed better and we always do a M_PURGE call before changing the interval. It's better to remove this legacy constraint. Full diff: https://github.com/llvm/llvm-project/pull/89114.diff 1 Files Affected:
diff --git a/compiler-rt/lib/scudo/standalone/wrappers_c.inc b/compiler-rt/lib/scudo/standalone/wrappers_c.inc
index 21d5b7add51275..28374548e39076 100644
--- a/compiler-rt/lib/scudo/standalone/wrappers_c.inc
+++ b/compiler-rt/lib/scudo/standalone/wrappers_c.inc
@@ -251,14 +251,6 @@ INTERFACE WEAK int SCUDO_PREFIX(mallopt)(int param, int value) {
// M_PURGE call so that we can minimize the impact of any unreleased pages
// introduced by interval transition.
SCUDO_ALLOCATOR.releaseToOS(scudo::ReleaseToOS::Force);
-
- if (value == 0) {
- // Will set the release values to their minimum values.
- value = INT32_MIN;
- } else {
- // Will set the release values to their maximum values.
- value = INT32_MAX;
- }
}
SCUDO_ALLOCATOR.setOption(scudo::Option::ReleaseInterval,
|
|
Based on the values allowed on Android, we may need to convert the values (-1, 0, 1) to ms, i.e., multiply 1000. But after reviewing few use cases of M_DECAY_TIME, I think we may still need to do some value mapping here. Will upload a new one. |
ChiaHungDuan
changed the title
| // Will set the release values to their maximum values. | ||
| // The values allowed on Android are {-1, 0, 1}. "1" means the longest | ||
| // interval. | ||
| if (value == 1) |
There was a problem hiding this comment.
Should this check be value > 0? That more closely matches what it did before.
There was a problem hiding this comment.
I'm thinking instead of ">=", maybe we can assert the range of values? given that only three values are valid. (And the description also says 0 and 1 are only allowed numbers)
There was a problem hiding this comment.
That would be fine with me. We sanitize the values when coming through Android anyway, so verifying a -1, 0, or 1 is probably a better way to do this.
There was a problem hiding this comment.
Done. CHECK added.
No description provided.