-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Refactor GC stats structs and names #50772
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.
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
base: master
Are you sure you want to change the base?
Conversation
So increase the amount for 32 bit and tests
3e19377
to
859c5b4
Compare
size_t localbytes = jl_atomic_load_relaxed(&ptls->gc_num.allocd) + gc_num.interval; | ||
jl_atomic_store_relaxed(&ptls->gc_num.allocd, -(int64_t)gc_num.interval); | ||
static_assert(sizeof(_Atomic(uint64_t)) == sizeof(gc_num.deferred_alloc), ""); | ||
jl_atomic_fetch_add((_Atomic(uint64_t)*)&gc_num.deferred_alloc, localbytes); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure we don't need anything like this anymore? When gc is disabled, we will start hitting a point where jl_gc_collect
is called and jl_gc_disable_counter
is atomically loaded on every allocation. Is that ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is one of the things I'm not super sure. One thing that we could do here is to set the next collection to a very high value so we don't try to enter it at all. And then forcibly run a gc when we reanable it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other is to update it with a simple default algorithm so that it does trigger but not so often.
On top of #50682