Many garbage-collected systems, including most that involve a stop-the-world phase, restrict GC to so called GC points. In single-threaded environments, GC points carry no overhead: when a GC must be done, the single thread is already at a GC point. In multi-threaded environments, however, only the thread that triggers the GC by failing an allocation will be at a GC point. Other threads must be rolled forward to their next GC point before the GC can take place. We compare, in the context of a high-performance Java^TM virtual machine, two approaches to advancing threads to a GC point, polling and code patching, while keeping all other factors constant. Code patching outperforms polling by an average of 4.7% and sometimes by as much as 11.2%, while costing only slightly more compiled code space. Put differently, since most programs spend less than 1/5 of the time in GC, a 4.7% bottom-line speedup amounts to more than a 20% reduction in the GC-related costs. Patching is, however, more difficult to implement.