From: Eric Wong Date: 2018-04-29T05:58:54+00:00 Subject: [ruby-core:86758] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC "Atdot.net" wrote: > Could you give us more detail algorithm? Pretty simple and I thought the patch was easy-to-read. Background is we can use ppoll with zero-timeout ({.tv_sec = 0, .tv_nsec = 0 }) to check and return immediately w/o releasing GVL. This means we can quickly check FD for readiness. This is a quick check and even optimized inside the Linux kernel[1]. thread_pthread.c also tracks GVL contention using .waiting field. I define GC-in-progress as (is_lazy_sweeping || is_incremental_packing) (same condition for gc.c:gc_rest() function) Therefore, if GVL is uncontended and GC has work to-do, we use zero-timeout ppoll and do incremental GC work (incremental mark + lazy sweep) as long as we need to wait on FD. If GC is done or if there is GVL contention, we fall back to use old code path and release GVL. For do_select case, it might be more expensive because select() is innefficient for high FDs; but if a process is otherwise not doing anything, I think it's OK to burn extra cycles to perform GC sooner. Unsubscribe: