GC is required for pinning / marking objects. If the compactor runs
without pinning everything, then it will blow up, so just return early
if the GC is disabled.
Objects in the finalizer table stay pinned for now. In some cases, the
key could move which would cause a miss when removing the object from
the table (leading to a T_MOVED reference staying in the table).
`obj_info` will look at references of objects in some cases (for example
it will try to access path information on ISeq objects). But during the
sweep phase, if the referenced object is collected before `obj_info` is
called, then it could be a bad ref and a segv will occur.
For example:
A -> B
Sweep phase:
1. obj_info(B)
2. Sweep and free B
3. obj_info(A); A tries to read B
4. SEGV
This commit simply removes the call to `obj_info` during the sweep
phase.
`GC::Profiler.enable; GC::Profiler.clear` tries to clear
objspace->profile.records but it has never been allocated before.
Thus the MEMCPY took NULL argument before this changeset.
The objspace->profile.records is allocated appropriately elsewhere.
Why not juts free it if any? That should work.
Depending on architectures, setjmp might not fully fill a jmp_buf.
On such machines the union can contain wobbly bits. They are then
scanned during mark_locations_array(). This is bad.
These assertions check if a newly allocated object (which is marked
as an uninitialized memory region in MSAN) is in fact a T_NONE.
Thus they intentionally read uninitialized memory regions, which do
not interface well with MSAN. Just disalbe them.
Before this commit, classes and modules would be registered with the
VM's `defined_module_hash`. The key was the ID of the class, but that
meant that it was possible for hash collisions to occur. The compactor
doesn't allow classes in the `defined_module_hash` to move, but if there
is a conflict, then it's possible a class would be removed from the hash
and not get pined.
This commit changes the key / value of the hash just to be the class
itself, thus preventing movement.
Remembered objects can move between pages, so we need to make sure the
flags on the page are set correctly.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67640 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Some classes don't have a superclass, so we should check to see if it's
there before marking.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67610 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
For some reason symbols (or classes) are being overridden in trunk
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67598 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This commit adds the new method `GC.compact` and compacting GC support.
Please see this issue for caveats:
https://bugs.ruby-lang.org/issues/15626
[Feature #15626]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67576 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Because hard to specify commits related to r67479 only.
So please commit again.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67499 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Weak map references can't move because the st_table needs their address
as a key. But, we also need to remove T_NONE from the map so they
aren't reused.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67485 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This commit adds the new method `GC.compact` and compacting GC support.
Please see this issue for caveats:
https://bugs.ruby-lang.org/issues/15626
[Feature #15626]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67479 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* gc.c (obj_memsize_of): T_RATIONAL and T_COMPLEX cannot be an
imemo.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67464 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This code was trying to access memory before unpoisoning it.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67417 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This commit just adds poisoning around the freelist to help debugging.
Also verify that the freelist only contains T_NONE objects when checking
the heap integrity
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67416 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
verify_internal_consistency_i and gc_verify_heap_page would walk the
heap, reading data from each slot, but would not unpoison the object
before reading. This commit unpoisons the slot before reading so that
we won't get ASAN errors
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67408 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
for types Float, Bignum and Symbol as they do not have references
and singleton classes.
[Fix GH-2091]
From: Lourens Naudé <lourens@bearmetal.eu>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67195 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This reverts commit r67078.
It breaks armv7l-linux-eabihf and sparc-solaris2.11.
20190215T061708Z.diff.html.gz
20190215T072546Z.diff.html.gz
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67080 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* internal.h: move ar_table def to hash.c because other files
don't need to know implementation of ar_table.
* hash.c (rb_hash_ar_table_size): added because gc.c needs to know
the size_of(ar_table).
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66638 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* gc.c (gc_mark_ptr): this check was introduced by accidentaly
(this is why message is "...", crazy simple) for debugging.
However, this check is useful because if there is T_NONE
object here, we can't know which object points to it.
For debugging reason, I remain this checking code and
set reasonable error message.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66514 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
