Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cap live_bytes to zero in a few places where GC intervals are computed #170

Merged
merged 2 commits into from
Aug 12, 2024
Merged

cap live_bytes to zero in a few places where GC intervals are computed #170

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
961f224
cap live_bytes to zero in a few places where GC intervals are computed
d-netto Jul 29, 2024
caef7e2
mem / log(mem) for interval upper bound
d-netto Aug 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 18 additions & 7 deletions src/gc.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
#ifdef __GLIBC__
#include <malloc.h> // for malloc_trim
#endif
#include <math.h>

#ifdef __cplusplus
extern "C" {
Expand Down Expand Up @@ -3669,29 +3670,39 @@ static int _jl_gc_collect(jl_ptls_t ptls, jl_gc_collection_t collection)
last_live_bytes = live_bytes;
live_bytes += -gc_num.freed + actual_allocd;

// XXX: we've observed that the `live_bytes` was negative in a few cases
// which is not expected. We should investigate this further, but let's just
// cap it to 0 for now.
int64_t live_bytes_for_interval_computation = live_bytes < 0 ? 0 : live_bytes;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we also want to cap it in the other direction? It should not exceed maximum memory, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I were to cap anything in the other direction (i.e. put an upper bound on anything), that would be the gc_num.interval, probably.

With this change, I believe it's already upper-bounded by max_total_memory, but we can possibly make that bound a bit tighter (i.e. max_total_memory / 2 or so).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is just a patch for v.1.10.2+RAI and not intended for upstream, could we limit gc_num.interval to max_total_memory / log2(max_total_memory) ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the motivation for dividing by log?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be more precise: why the choice of log here? And not some other function?

Copy link

@tveldhui tveldhui Aug 8, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The OOMGuardian heuristic triggers full gc when the heap size increases by 15% over the high-water mark in a rolling window (10 minutes). This avoids having the heap be more than 15% larger than it needs to be (resulting in shorter gc pauses and fewer TLB misses in pointer dereferences). It also means that if the reachable heap size is increasing monotonically, we don't do more than a logarithmic number of collections. In the scenario where we don't know the actual heap size because of the accounting problem, I'm going for a logarithmic number of collections in physical memory size. The max_total_memory / log2(max_total_memory) calculation would give an interval of 0.5GiB for 16GiB ram (32 collections until all of physical memory allocated), and 6.7GiB for 256GiB ram (38 collections).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implemented in latest commit.


if (collection == JL_GC_AUTO) {
//If we aren't freeing enough or are seeing lots and lots of pointers let it increase faster
if (not_freed_enough || large_frontier) {
int64_t tot = 2 * (live_bytes + actual_allocd) / 3;
int64_t tot = 2 * (live_bytes_for_interval_computation + actual_allocd) / 3;
if (gc_num.interval > tot) {
gc_num.interval = tot;
last_long_collect_interval = tot;
}
}
// If the current interval is larger than half the live data decrease the interval
else {
int64_t half = (live_bytes / 2);
int64_t half = (live_bytes_for_interval_computation / 2);
if (gc_num.interval > half)
gc_num.interval = half;
}
// But never go below default
if (gc_num.interval < default_collect_interval) gc_num.interval = default_collect_interval;
if (gc_num.interval < default_collect_interval)
gc_num.interval = default_collect_interval;
// And never go above the upper bound
const int64_t interval_upper_bound = (int64_t)((double)max_total_memory / log2((double)max_total_memory));
if (gc_num.interval > interval_upper_bound)
gc_num.interval = interval_upper_bound;
}

if (gc_num.interval + live_bytes > max_total_memory) {
if (live_bytes < max_total_memory) {
gc_num.interval = max_total_memory - live_bytes;
last_long_collect_interval = max_total_memory - live_bytes;
if (gc_num.interval + live_bytes_for_interval_computation > max_total_memory) {
if (live_bytes_for_interval_computation < max_total_memory) {
gc_num.interval = max_total_memory - live_bytes_for_interval_computation;
d-netto marked this conversation as resolved.
Show resolved Hide resolved
last_long_collect_interval = max_total_memory - live_bytes_for_interval_computation;
}
else {
// We can't stay under our goal so let's go back to
Expand Down