This `st_table` is used to both mark and pin classes
defined from the C API. But `vm->mark_object_ary` already
does both much more efficiently.
Currently a Ruby process starts with 252 rooted classes,
which uses `7224B` in an `st_table` or `2016B` in an `RArray`.
So a baseline of 5kB saved, but since `mark_object_ary` is
preallocated with `1024` slots but only use `405` of them,
it's a net `7kB` save.
`vm->mark_object_ary` is also being refactored.
Prior to this changes, `mark_object_ary` was a regular `RArray`, but
since this allows for references to be moved, it was marked a second
time from `rb_vm_mark()` to pin these objects.
This has the detrimental effect of marking these references on every
minors even though it's a mostly append only list.
But using a custom TypedData we can save from having to mark
all the references on minor GC runs.
Addtionally, immediate values are now ignored and not appended
to `vm->mark_object_ary` as it's just wasted space.
assert does not print the bug report, only the file and line number of
the assertion that failed. RUBY_ASSERT prints the full bug report, which
makes it much easier to debug.
[Bug #19390]
We shouldn't check the string length when skipping zeros, as the
string might only contains zero characters, resulting in an empty string.
... because BDIGIT_DBL may be long long. POSFIXABLE and NEGFIXABLE
ensures that the value is representable as long, but it failed to build
on emscripten with -Werror -Wshorten-64-to-32.
It uses random to determine if the bignum is sparse or not.
It is arguable if three-digit samples are enough or not to determine it,
but anyway, consuming Random source implicitly is not good.
I introduced the random sampling mechanism, and I don't know any
significant reason to do so. So, let's remove it.
This change makes the sampling points fixed: 40th, 50th, and 60th
percentiles.
Starting GCC 7, warnings about uninitialized variables are issued around
them. Such warnings could be false positives (all versions of clang do
not warn), but adding initializers there could never be bad things.
I struggled figuring out which of the pack/unpack functions goes into which direction and the two first sentences were of the documentation were:
* Import an integer into a buffer.
* Export an integer into a buffer.
It sounds like both of them go from a ruby integer to a buffer because both use "into". So I fixed it and went to "Import an integer from a buffer". I find this much more clear.
tompng
Jean Boussier
Yusuke Endoh
Peter Zhu
Nobuyoshi Nakada
git
Matt Valentine-House
Takashi Kokubun
S-H-GAMELINKS
Marcus Stollsteimer
Kazuhiro NISHIYAMA
卜部昌平
Bernhard F. Brodowsky
Kenta Murata