| Age | Commit message (Collapse) | Author |
|
This heap emulates the growth characteristics of the Ruby default GC's
heap. By default, the heap grows by 40%, requires at least 20% empty
after a GC, and allows at most 65% empty before it shrinks the heap. This
is all configurable via the same environment variables the default GC
uses (`RUBY_GC_HEAP_FREE_SLOTS_GOAL_RATIO`, `RUBY_GC_HEAP_FREE_SLOTS_MIN_RATIO`,
`RUBY_GC_HEAP_FREE_SLOTS_MAX_RATIO`, respectively).
The Ruby heap can be enabled via the `MMTK_HEAP_MODE=ruby` environment
variable.
Compared to the dynamic heap in MMTk (which uses the MemBalancer algorithm),
the Ruby heap allows the heap to grow more generously, which uses a bit
more memory but offers significant performance gains because it runs GC
much less frequently.
We can see in the benchmarks below that this Ruby heap heap gives faster
performance than the dynamic heap in every benchmark, with over 2x faster
in many of them. We see that memory is often around 10-20% higher with
certain outliers that use significantly more memory like hexapdf and
erubi-rails. We can also see that this brings MMTk's Ruby heap much
closer in performance to the default GC.
Ruby heap benchmark results:
-------------- -------------- ---------- ---------
bench ruby heap (ms) stddev (%) RSS (MiB)
activerecord 233.6 10.7 85.9
chunky-png 457.1 1.1 79.3
erubi-rails 1148.0 3.8 133.3
hexapdf 1570.5 2.4 403.0
liquid-c 42.8 5.3 43.4
liquid-compile 41.3 7.6 52.6
liquid-render 102.8 3.8 55.3
lobsters 651.9 8.0 426.3
mail 106.4 1.8 67.2
psych-load 1552.1 0.8 43.4
railsbench 1707.2 6.0 145.6
rubocop 127.2 15.3 148.8
ruby-lsp 136.6 11.7 113.7
sequel 47.2 5.9 44.4
shipit 1197.5 3.6 301.0
-------------- -------------- ---------- ---------
Dynamic heap benchmark results:
-------------- ----------------- ---------- ---------
bench dynamic heap (ms) stddev (%) RSS (MiB)
activerecord 845.3 3.1 76.7
chunky-png 525.9 0.4 38.9
erubi-rails 2694.9 3.4 115.8
hexapdf 2344.8 5.6 164.9
liquid-c 73.7 5.0 40.5
liquid-compile 107.1 6.8 40.3
liquid-render 147.2 1.7 39.5
lobsters 697.6 4.5 342.0
mail 224.6 2.1 64.0
psych-load 4326.7 0.6 37.4
railsbench 3218.0 5.5 124.7
rubocop 203.6 6.1 110.9
ruby-lsp 350.7 3.2 79.0
sequel 121.8 2.5 39.6
shipit 1510.1 3.1 220.8
-------------- ----------------- ---------- ---------
Default GC benchmark results:
-------------- --------------- ---------- ---------
bench default GC (ms) stddev (%) RSS (MiB)
activerecord 148.4 0.6 67.9
chunky-png 440.2 0.7 57.0
erubi-rails 722.7 0.3 97.8
hexapdf 1466.2 1.7 254.3
liquid-c 32.5 3.6 42.3
liquid-compile 31.2 1.9 35.4
liquid-render 88.3 0.7 30.8
lobsters 633.6 7.0 305.4
mail 76.6 1.6 53.2
psych-load 1166.2 1.3 29.1
railsbench 1262.9 2.3 114.7
rubocop 105.6 0.8 95.4
ruby-lsp 101.6 1.4 75.4
sequel 27.4 1.2 33.1
shipit 1083.1 1.5 163.4
-------------- --------------- ---------- ---------
https://github.com/ruby/mmtk/commit/c0ca29922d
|
|
Adding a fast path for bump pointer allocator can improve allocation
performance.
For the following microbenchmark with MMTK_HEAP_MIN=100MiB:
10_000_000.times { String.new }
Before:
810.7 ms ± 8.3 ms [User: 790.9 ms, System: 40.3 ms]
After:
777.9 ms ± 10.4 ms [User: 759.0 ms, System: 37.9 ms]
https://github.com/ruby/mmtk/commit/0ff5c9f579
|
|
This will allow the Ruby backtrace, memory mapping, etc. to be outputted
when a Ruby mutator thread panics.
https://github.com/ruby/mmtk/commit/d10fd325dd
|
|
If a reference marked weak becomes a special const, it will crash because
it is not a GC handled object. We should skip special consts here.
https://github.com/ruby/mmtk/commit/870a79426b
|
|
https://github.com/ruby/mmtk/commit/84975a8840
|
|
https://github.com/ruby/mmtk/commit/45f991578e
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13610
|
|
Ues more idiomatic rust approaches.
https://github.com/ruby/mmtk/commit/ef125f9eae
|
|
We also enable `#![warn(unsafe_op_in_unsafe_fn)]` in the whole mmtk_ruby
crate.
https://github.com/ruby/mmtk/commit/8b8025f71a
|
|
Remove the unused constant HAS_MOVED_GFIELDSTBL and related methods.
In the mmtk/mmtk-ruby repo, we are now able to find the global field
(IV) table of a moved object during copying GC without using the
HAS_MOVED_GFIELDSTBL bit. We synchronize some of the code, although we
haven't implemented moving GC in ruby/mmtk, yet.
See: https://github.com/mmtk/mmtk-ruby/commit/13080acdf553f20a88a7ea9ab9f6877611017136
https://github.com/ruby/mmtk/commit/400ba4e747
|
|
And get rid of the `obj_to_id_tbl`
It's no longer needed, the `object_id` is now stored inline
in the object alongside instance variables.
We still need the inverse table in case `_id2ref` is invoked, but
we lazily build it by walking the heap if that happens.
The `object_id` concern is also no longer a GC implementation
concern, but a generic implementation.
Co-Authored-By: Matt Valentine-House <matt@eightbitraptor.com>
Notes:
Merged: https://github.com/ruby/ruby/pull/13159
|
|
Ivars will longer be the only thing stored inline
via shapes, so keeping the `iv_index` and `ivptr` names
would be confusing.
Instance variables won't be the only thing stored inline
via shapes, so keeping the `ivptr` name would be confusing.
`field` encompass anything that can be stored in a VALUE array.
Similarly, `gen_ivtbl` becomes `gen_fields_tbl`.
Notes:
Merged: https://github.com/ruby/ruby/pull/13159
|
|
We rely on scan_vm_specific_roots to reach all stacks via the following
path:
VM -> ractors -> threads -> fibers -> stacks
https://github.com/ruby/mmtk/commit/0a6a835aaa
|
|
We now use `MMTK::handle_user_collection_request(true, ...)` to force
triggering a GC instead of enabling GC temporarily.
https://github.com/ruby/mmtk/commit/02ef47f818
|
|
https://github.com/ruby/mmtk/commit/9da566e26a
|
|
https://github.com/ruby/mmtk/commit/e52b973611
|
|
https://github.com/ruby/mmtk/commit/6a78ffaf16
|
|
https://github.com/ruby/mmtk/commit/5bbac70c69
|
|
https://github.com/ruby/mmtk/commit/810f897603
|
|
https://github.com/ruby/mmtk/commit/67da9ea5b8
|
|
https://github.com/ruby/mmtk/commit/836a9059cb
|
|
https://github.com/ruby/mmtk/commit/79ce2008a3
|
|
https://github.com/ruby/mmtk/commit/c8b1f4c156
|
|
https://github.com/ruby/mmtk/commit/4a24d55d91
|
|
https://github.com/ruby/mmtk/commit/1d2f7b9cfc
|
|
https://github.com/ruby/mmtk/commit/5c5c454f65
|
|
UNIQUE_OBJECT_ENQUEUING guarantees that object marking is atomic so that
an object cannot be marked more than once.
https://github.com/ruby/mmtk/commit/2f97fd8207
|
|
https://github.com/ruby/mmtk/commit/e4d6b56824
|
|
This commit implements the mark-sweep algorithm using MMTk and allows
customizing the plan using MMTK_PLAN.
https://github.com/ruby/mmtk/commit/6fea5e5ffc
Co-Authored-By: Matt Valentine-House <matt@eightbitraptor.com>
|
|
This commit only supports initializing MMTk with NoGC and object
allocation.
https://github.com/ruby/mmtk/commit/39aa10e537
Co-Authored-By: Kunshan Wang <wks1986@gmail.com>
|