@byroot Maybe what we need for Ruby GC is some kind of setting where Ruby can signal it _needs_ to GC, but doesn't actually do it. Then, app servers can GC out of band when the signal is true.

e.g.

GC.required? #> true
... Unicorn GCs out-of-band at next opportunity.

Having to tune the number of requests until you want to OOBGC sucks.

2
Share
Share on Mastodon
Share on Twitter
Share on Facebook
Share on Linkedin
Richard Schneeman

@nateberkopec @byroot it still needs to free up some space for objects (or allocate).

I could maybe see a pattern where it just runs incremental GC and then sets a flag, but I don’t think you can ever eliminate a full sweep as there is always the case that that even a major GC won’t free up what it needs and it will have to allocate.

Maybe it could allocate with a small amount naively and then set a flag and we could ask Ruby to be consider freeing that extra allocation.

0
1y
Jean Boussier

@nateberkopec The problem I see with this is that if the request allocates a lot, it might need to trigger it synchronously anyway.

I think I'd prefer a way to tell if we're close to need one or not, which is more or less github.com/ruby/ruby/pull/6791 (I need to dig into that one more)

0
1y
Replies