dde164e968
Currently, the number of incremental marking steps is calculated based on the number of pooled pages available. This means that if we make Ruby heap pages larger, it would run fewer incremental marking steps (which would mean each incremental marking step takes longer). This commit changes incremental marking to run after every INCREMENTAL_MARK_STEP_ALLOCATIONS number of allocations. This means that the behaviour of incremental marking remains the same regardless of the Ruby heap page size. I've benchmarked against discourse benchmarks and did not get a significant change in response times beyond the margin of error. This is expected as this new incremental marking algorithm behaves very similarly to the previous one. |
||
|---|---|---|
| .. | ||
| array.h | ||
| bignum.h | ||
| bits.h | ||
| class.h | ||
| cmdlineopt.h | ||
| compar.h | ||
| compile.h | ||
| compilers.h | ||
| complex.h | ||
| cont.h | ||
| dir.h | ||
| enc.h | ||
| encoding.h | ||
| enum.h | ||
| enumerator.h | ||
| error.h | ||
| eval.h | ||
| file.h | ||
| fixnum.h | ||
| gc.h | ||
| hash.h | ||
| imemo.h | ||
| inits.h | ||
| io.h | ||
| load.h | ||
| loadpath.h | ||
| math.h | ||
| missing.h | ||
| numeric.h | ||
| object.h | ||
| parse.h | ||
| proc.h | ||
| process.h | ||
| ractor.h | ||
| random.h | ||
| range.h | ||
| rational.h | ||
| re.h | ||
| sanitizers.h | ||
| serial.h | ||
| signal.h | ||
| static_assert.h | ||
| string.h | ||
| struct.h | ||
| symbol.h | ||
| thread.h | ||
| time.h | ||
| transcode.h | ||
| util.h | ||
| variable.h | ||
| vm.h | ||
| warnings.h | ||