The `MEMOIZE_LOOKAROUND_MATCH_CACHE_POINT` macro needs an argument
otherwise we end up with:
```
../regexec.c:3955:2: error: called object type 'void' is not a function or function pointer
3955 | STACK_POS_END(stkp);
| ^~~~~~~~~~~~~~~~~~~
../regexec.c:1680:41: note: expanded from macro 'STACK_POS_END'
1680 | MEMOIZE_LOOKAROUND_MATCH_CACHE_POINT(k);\
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
../regexec.c:3969:7: error: called object type 'void' is not a function or function pointer
3969 | STACK_POP_TIL_POS_NOT;
| ^~~~~~~~~~~~~~~~~~~~~
../regexec.c:1616:41: note: expanded from macro 'STACK_POP_TIL_POS_NOT'
1616 | MEMOIZE_LOOKAROUND_MATCH_CACHE_POINT(stk);\
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
```
The macro definition with the match cache enabled already has the
correct argument. This one is for when the match cache is disabled (I
had disabled it while trying to learn more about how it works.)
It looks like stat_insn_usage was introduced with YARV, but as far as I
can tell the field has never been used. I think we should remove the
field since we don't use it.
mutable constants can't be shared across ractors; this changes that design to define the required variables as constants on the Resource class, which makes them reachable using ractors; the ClassHash is kept in order not to break integrations relying on its existence, but under the hood it's doing the same thing
https://github.com/ruby/resolv/commit/639c01dc7f
Originally, if a class was defined with the class keyword, the cref had a
const_added callback, and the superclass an inherited callback, const_added was
called first, and inherited second.
This was discussed in
https://bugs.ruby-lang.org/issues/21143
and an attempt at changing this order was made.
While both constant assignment and inheritance have happened before these
callbacks are invoked, it was deemed nice to have the same order as in
C = Class.new
This was mostly for alignment: In that last use case things happen at different
times and therefore the order of execution is kind of obvious, whereas when the
class keyword is involved, the order is opaque to the user and it is up to the
interpreter.
However, soon in
https://bugs.ruby-lang.org/issues/21193
Matz decided to play safe and keep the existing order.
This reverts commits:
de097fbe5f3df105bd2a26e72db06b0f5139bc1a
de48e47ddf78aba02fd9623bc7ce685540a10743
In ruby/ruby#13008 `RVALUE` was removed without replacement. This means
the lldb scripts that relied on `RVALUE` stopped working.
I updated the ones that were using it just for the bytesize to use
`slot_size` and then round to the nearest power of 40. We can't use
`slot_size` directly because in debug mode it's `48` but `RVALUE` is
`40` bytes.
For the `as_type` method, I updated it to check the type. It's only used
for `bignum` and `array` so that's a simple change.
Lastly, for the `dump_page` method I replaced it with `struct free_slot`
since that's looking at the freelist.
`struct RVALUE` has been removed from all the scripts and I verified
that `rp` is fixed. I'm not confident the `dump_page` method is fixed,
the freelist looks off, but for now this gets us closer.
These assertions didn't handle drive letter of Windows
```
1) Failure:
TestFileExhaustive#test_dirname [V:/github.com/ruby/ruby/test/ruby/test_file_exhaustive.rb:1282]:
<"V:/"> expected but was
<"C:/">.
```
The spinlock here performs poorly when there are multiple Ractors. The
improvement on single threaded performance doesn't seem that
significant, so I think we should just use malloc.
[Bug #21214]
If we allocate objects where one heap holds transient objects and another
holds long lived objects, then the heap with transient objects will grow
along the heap with long lived objects, causing higher memory usage.
For example, we can see this issue in this script:
def allocate_small_object = []
def allocate_large_object = Array.new(10)
arys = Array.new(1_000_000) do
# Allocate 10 small transient objects
10.times { allocate_small_object }
# Allocate 1 large object that is persistent
allocate_large_object
end
pp GC.stat
pp GC.stat_heap
Before this change:
heap_live_slots: 2837243
{0 =>
{slot_size: 40,
heap_eden_pages: 1123,
heap_eden_slots: 1838807},
2 =>
{slot_size: 160,
heap_eden_pages: 2449,
heap_eden_slots: 1001149},
}
After this change:
heap_live_slots: 1094474
{0 =>
{slot_size: 40,
heap_eden_pages: 58,
heap_eden_slots: 94973},
2 =>
{slot_size: 160,
heap_eden_pages: 2449,
heap_eden_slots: 1001149},
}
`Integer.sqrt` uses `sqrt(3)` from libm for small values.
This method must return a value less than or equal to the actual integer
square root, but libm's sqrt does not always guarantee that.
This change corrects that by decrementing the result if necessary.
Fixes [Bug #21217]
