[#115244] [Ruby master Feature#19987] add sample method to Range — "horv77@... (Andras Horvath) via ruby-core" <ruby-core@...>
Issue #19987 has been reported by [email protected] (Andras Horvath).
6 messages
2023/11/05
[#115247] [Ruby master Feature#19988] AI for inner code behavior analysis at runtime — "horv77@... (Andras Horvath) via ruby-core" <ruby-core@...>
Issue #19988 has been reported by [email protected] (Andras Horvath).
3 messages
2023/11/05
[#115404] Ruby 3.2.2 - rbconfig.rb's MAKEFILE_CONFIG — Jay Mav via ruby-core <ruby-core@...>
Hello Ruby Dev Team,
4 messages
2023/11/17
[ruby-core:115504] [Ruby master Bug#20022] GC.verify_compaction_references does not actually move all objects
From:
"kjtsanaktsidis (KJ Tsanaktsidis) via ruby-core" <ruby-core@...>
Date:
2023-11-28 11:07:16 UTC
List:
ruby-core #115504
Issue #20022 has been updated by kjtsanaktsidis (KJ Tsanaktsidis).
> If we figure out the optimal size of every object and we set the heap to size (optimal_size * 2) + 1, it should guarantee that every object is moved before the cursors meet.
This sounds like a good idea (not least because it avoids hacking at the actual compaction implementation just for this development tool). Unfortunately I don't think the right formula is _quite_ that simple. 2N+1 isn't enough pages for all of the test cases - I added some iterations to some of the other move up/down test cases and they fail. They fail worse if I make them move up/down by more than one size pool... so I'm thinking the right factor has something to do with what size pool objects are coming from as well as going to (e.g. something along these lines:)
```
size_t weighting_factor = 1;
if (dest_pool->slot_size > page->size_pool->slot_size) {
weighting_factor <<= (dest_pool - page->size_pool);
} else if (dest_pool->slot_size < page->size_pool->slot_size) {
weighting_factor <<= (page->size_pool - dest_pool);
}
tdata->required_slots_weighted[dest_pool_idx] += weighting_factor;
```
This isn't quite it either though.
I haven't been able to figure out the right formula yet but I'll try and have another go over the weekend... in the meanwhile I pushed up some WIP to my branch if you have a bright idea about the right formula.
----------------------------------------
Bug #20022: GC.verify_compaction_references does not actually move all objects
https://bugs.ruby-lang.org/issues/20022#change-105433
* Author: kjtsanaktsidis (KJ Tsanaktsidis)
* Status: Open
* Priority: Normal
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
While debugging https://bugs.ruby-lang.org/issues/20021, I ran into a separate issue which I figured was worth resolving whilst I had it in my head.
The intention of GC.verify_compaction_references is, I believe, to force every single movable object to be moved, so that it's possible to debug native extensions which not correctly updating their references to objects they mark as movable (if this is _not_ the case, you can stop reading now and accept my apologies!)
To do this, it doubles the number of allocated pages for each size pool, and sorts the heap pages so that the free ones are swept first; thus, every object in an old page should be moved into a free slot in one of the new pages.
This worked fine until movement of objects between size pools during compaction was implemented. That causes some problems for verify_compaction_references:
- We were doubling the number of pages in each size pool, but actually if some objects need to move into a different pool, there's no guarantee that they'll be enough room in that one.
- It's possible for the sweep & compact cursors to meet in one size pool before all the objects that want to move into that size pool from another are processed by the compaction.
You can see these problems by changing some of the movement tests in test_gc_compact.rb to try and move e.g. 50,000 objects instead of 500 (by changing `HASH_COUNT`); the test is not able to actually move all of the objects in a single compaction run.
What I implemented in this PR (https://github.com/ruby/ruby/pull/9041) is two things:
- Firstly, it examines every object and determine where it wants to be compacted into; we use this information to calculate the desired number of pages to add to each size pool.
- Secondly, it compacts twice; once in order of ascending size pool, and once descending. This means that we are guaranteed to be able to move everything we want to move into a size pool before we start advancing that pool's own compact cursor.
With these fixes in place, I was able to make the compaction tests move any amount of objects (previously, `test_moving_hashes_down_size_pools` would begin failing on my machine if I set `HASH_COUNT` to above about 6,000.
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- [email protected]
To unsubscribe send an email to [email protected]
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/