Dump outer variables tables when dumping an iseq to binary
This commit dumps the outer variables table when dumping an iseq to
binary. This fixes a case where Ractors aren't able to tell what outer
variables belong to a lambda after the lambda is loaded via ISeq.load_from_binary
[Bug #18232] [ruby-core:105504]
---
compile.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++-
test/ruby/test_iseq.rb | 10 +++++++++
2 files changed, 64 insertions(+), 1 deletion(-)
cdhash_cmp: can take rational literals
Rational literals are those integers suffixed with `r`. They tend to
be a part of more complex expressions like `123/456r`, but in theory
they can live alone. When such "bare" rational literals are passed to
case-when branch, we have to take care of them. Fixes [Bug #17854]
---
common.mk | 1 +
compile.c | 7 +++++++
internal/rational.h | 1 +
rational.c | 13 ++++++++++---
test/ruby/test_rational.rb | 7 +++++++
5 files changed, 26 insertions(+), 3 deletions(-)
cdhash_cmp: rational literals with fractions
Nobu kindly pointed out that rational literals can have fractions.
---
compile.c | 5 +++--
test/ruby/test_rational.rb | 4 ++++
2 files changed, 7 insertions(+), 2 deletions(-)
cdhash_cmp: can also take complex
There are complex literals `123i`, which can also be a case condition.
---
compile.c | 15 +++++++++++----
complex.c | 12 +++++++++---
internal/complex.h | 1 +
test/ruby/test_rational.rb | 4 ++++
4 files changed, 25 insertions(+), 7 deletions(-)
cdhash_cmp: recursively apply
For instance a rational's numerator can be a bignum. Comparison using
C's == can be insufficient.
---
compile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
cdhash_cmp: should use ||
cf: https://github.com/ruby/ruby/pull/4469#discussion_r628386707
---
compile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
test_cdhash: refactor change class
It is now strange to test Complex in a class named Rational_Test.
---
test/ruby/test_rational.rb | 15 ---------------
test/ruby/test_syntax.rb | 15 +++++++++++++++
2 files changed, 15 insertions(+), 15 deletions(-)
compile.c: stop the jump-jump optimization if the second has any
event
Fixes [Bug #17868]
---
compile.c | 3 ++-
test/ruby/test_settracefunc.rb | 15 +++++++++++++++
2 files changed, 17 insertions(+), 1 deletion(-)
Mark pattern labels as unremoveable
Peephole optimization doesn't play well with find pattern at
least. The only case when a pattern matching could have
unreachable patterns is when we have lasgn/dasgn node, which
shouldn't happen in real-life.
Fixes https://bugs.ruby-lang.org/issues/17534
---
compile.c | 2 +-
test/ruby/test_pattern_matching.rb | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletion(-)
Guard callinfo
Callinfo was being written in to an array and the GC would not see the
reference on the stack. `new_insn_send` creates a new callinfo object,
then it calls `new_insn_core`. `new_insn_core` allocates a new INSN
linked list item, which can end up calling `xmalloc` which will trigger
a GC:
70cd351c7c/compile.c (L968-L969)
Since the callinfo object isn't on the stack, the GC won't see it, and
it can get collected. This patch just refactors `new_insn_send` to keep
the object on the stack
Co-authored-by: John Hawthorn <john@hawthorn.email>
---
compile.c | 7 +++++--
test/ruby/test_gc.rb | 10 ++++++++++
2 files changed, 15 insertions(+), 2 deletions(-)
Fix WB for callinfo
The WB for callinfo needs to be executed *after* the reference is
written. Otherwise we get a WB miss.
---
compile.c | 1 +
1 file changed, 1 insertion(+)
constant cache `IC` is accessed by non-atomic manner and there are
thread-safety issues, so Ruby 3.0 disables to use const cache on
non-main ractors.
This patch enables it by introducing `imemo_constcache` and allocates
it by every re-fill of const cache like `imemo_callcache`.
[Bug #17510]
Now `IC` only has one entry `IC::entry` and it points to
`iseq_inline_constant_cache_entry`, managed by T_IMEMO object.
`IC` is atomic data structure so `rb_mjit_before_vm_ic_update()` and
`rb_mjit_after_vm_ic_update()` is not needed.
Previously we would add code to check if an ivar was defined when using
`@foo ||= 123`, which was slower than `@foo || (@foo = 123)` when `@foo`
was already defined.
Recently 01b7d5acc7 made it so that
accessing an undefined variable no longer generates a warning, making
the defined check unnecessary and both statements exactly equal.
This commit avoids emitting the defined instruction when compiling
NODE_OP_ASGN_OR with a NODE_IVAR.
Before:
$ ruby --dump=insn -e '@foo ||= 123'
== disasm: #<ISeq:<main>@-e:1 (1,0)-(1,12)> (catch: FALSE)
0000 putnil ( 1)[Li]
0001 defined instance-variable, :@foo, false
0005 branchunless 14
0007 getinstancevariable :@foo, <is:0>
0010 dup
0011 branchif 20
0013 pop
0014 putobject 123
0016 dup
0017 setinstancevariable :@foo, <is:0>
0020 leave
After:
$ ./ruby --dump=insn -e '@foo ||= 123'
== disasm: #<ISeq:<main>@-e:1 (1,0)-(1,12)> (catch: FALSE)
0000 getinstancevariable :@foo, <is:0> ( 1)[Li]
0003 dup
0004 branchif 13
0006 pop
0007 putobject 123
0009 dup
0010 setinstancevariable :@foo, <is:0>
0013 leave
This seems to be about 50% faster in this benchmark:
require "benchmark/ips"
class Foo
def initialize
@foo = nil
end
def test1
@foo ||= 123
end
def test2
@foo || (@foo = 123)
end
end
FOO = Foo.new
Benchmark.ips do |x|
x.report("test1", "FOO.test1")
x.report("test2", "FOO.test2")
end
Before:
$ ruby benchmark_ivar.rb
Warming up --------------------------------------
test1 1.957M i/100ms
test2 3.125M i/100ms
Calculating -------------------------------------
test1 20.030M (± 1.7%) i/s - 101.780M in 5.083040s
test2 31.227M (± 4.5%) i/s - 156.262M in 5.015936s
After:
$ ./ruby benchmark_ivar.rb
Warming up --------------------------------------
test1 3.205M i/100ms
test2 3.197M i/100ms
Calculating -------------------------------------
test1 32.066M (± 1.1%) i/s - 163.440M in 5.097581s
test2 31.438M (± 4.9%) i/s - 159.860M in 5.098961s
* `GC.auto_compact=`, `GC.auto_compact` can be used to control when
compaction runs. Setting `auto_compact=` to true will cause
compaction to occurr duing major collections. At the moment,
compaction adds significant overhead to major collections, so please
test first!
[Feature #17176]
iv_index_tbl manages instance variable indexes (ID -> index).
This data structure should be synchronized with other ractors
so introduce some VM locks.
This patch also introduced atomic ivar cache used by
set/getinlinecache instructions. To make updating ivar cache (IVC),
we changed iv_index_tbl data structure to manage (ID -> entry)
and an entry points serial and index. IVC points to this entry so
that cache update becomes atomically.
The write barrier wasn't being called for this object, so add the
missing WB. Automatic compaction moved the reference because it didn't
know about the relationship (that's how I found the missing WB).
This commit introduces Ractor mechanism to run Ruby program in
parallel. See doc/ractor.md for more details about Ractor.
See ticket [Feature #17100] to see the implementation details
and discussions.
[Feature #17100]
This commit does not complete the implementation. You can find
many bugs on using Ractor. Also the specification will be changed
so that this feature is experimental. You will see a warning when
you make the first Ractor with `Ractor.new`.
I hope this feature can help programmers from thread-safety issues.
This reverts commit 3a4be429b5.
To fix following warning:
```
compiling ../compile.c
../compile.c:6336:20: warning: variable 'line' is uninitialized when used here [-Wuninitialized]
ADD_INSN(head, line, putnil); /* allocate stack for cached #deconstruct value */
^~~~
../compile.c:220:57: note: expanded from macro 'ADD_INSN'
ADD_ELEM((seq), (LINK_ELEMENT *) new_insn_body(iseq, (line), BIN(insn), 0))
^~~~
../compile.c:6327:13: note: initialize the variable 'line' to silence this warning
int line;
^
= 0
1 warning generated.
```
Use ID instead of GENTRY for gvars.
Global variables are compiled into GENTRY (a pointer to struct
rb_global_entry). This patch replace this GENTRY to ID and
make the code simple.
We need to search GENTRY from ID every time (st_lookup), so
additional overhead will be introduced.
However, the performance of accessing global variables is not
important now a day and this simplicity helps Ractor development.
