The only remaining use of this function was to get the internal
message object from an exception's hidden `mesg` instance
variable to allow it to be dumped wiithout converting to a string.
As discussed in #103, this exposes internal implementation details
of CRuby, and ultimately does not provide any real utility to the
user since they can't directly inspect this hidden variable. The
test change here is to reflect CRuby behavior that denies equality
if the internal message objects do not match, as is the case after
the exception has been loaded and now has a simple String value.
The impact to users is that exceptions with special hidden message
objects will convert those objects to String during marshaling
through YAML. I believe this only affects NameError and its
descendants, since users can't set this field directly on their
own exception types.
Fixes#103.
Now that RUBY_ALIGNOF behaves like C11's _Alignof. This is not
necessarily the best stack arrangement. We can just give up using
__builtin_alloca_with_align(), and let alloca choose what is optimal.
It is reported that on a system of i386 System V ABI, GCC returns 8 for
__alignof__(double). OTOH the ABI defines alignments of double to be 4,
and ISO/IEC 9899:2011 reads that _Alignof(double) shall return 4 on such
machine. What we want in ruby is 4 instead of 8 there. We cannot use
__alignof__.
Additionally, both old GCC / old clang return 8 for _Alignof(double) on
such platforms. They are their bugs, and already fixed in recent
versions. But we have to support older compilers for a while. Shall
check sanity of _Alignof.
Availability of `alignas` is checked in include/ruby/internal/stdalign.h
now. That does not need this configure check. Also as commented in the
header, we see `_Alignas` being inadequate for our purpose.
Ractor#close_outgoing should cancel waiting Ractor.yield. However,
yield a value by the Ractor's block should not cancel (to recognize
terminating Ractor, introduce rb_ractor_t::yield_atexit flag).
JRuby's environment variables are provided by the Java Development
Kit's (JDK's) classes, which present them as a map from string to
string. In order to do this, those environment variable names and
values must be decoded into characters, which breaks any variables
that are intended to be "raw" bytes not necessarily decodable with
the default system encoding.
This issue is detailed in jruby/jruby#6248. The only solution on
the JRuby side will be to bypass the JDK environment variable API
and go directly to the native getenv/setenv system calls. This is
not likely to happen in the near future, due to the complexity of
such a change and the rarity of undecodable environment values.
The exclude here was added due to the Windows platform also having
a similar sensitivity to character encodings when working with
environment variables. It seems appropriate to expand this skip
to the "java" platform, as the root issue is largely the same.
https://github.com/ruby/webrick/commit/dc453e5c3c
On some environments that uses OpenSSL 1.1.1h, the two tests now fail.
http://rubyci.s3.amazonaws.com/android29-x86_64/ruby-master/log/20200924T062352Z.fail.html.gzhttps://github.com/ruby/ruby/runs/1159288773?check_suite_focus=true
```
1) Failure:
TestNetHTTPS#test_get [/data/data/com.termux/files/home/cb/tmp/build/20200924T062352Z/ruby/test/net/http/test_https.rb:47]:
<"0\x82\x03\xED0\x82\x02\xD5\xA0\x03..."> expected but was
<"0\x82\x03\xE30\x82\x02\xCB\xA0\x03...">.
```
Not sure why, but verify_callback now seems to receive only SERVER_CERT
but not CA_CERT.
It would be good to investigate the issue furthermore, but tentatively,
I want to stop the failures.
This PR improves the performance of `super` calls. While working on some
Rails optimizations jhawthorn discovered that `super` calls were slower
than expected.
The changes here do the following:
1) Adds a check for whether the call frame is not equal to the method
entry iseq. This avoids the `rb_obj_is_kind_of` check on the next line
which is quite slow. If the current call frame is equal to the method
entry we know we can't have an instance eval, etc.
2) Changes `FL_TEST` to `FL_TEST_RAW`. This is safe because we've
already done the check for `T_ICLASS` above.
3) Adds a benchmark for `T_ICLASS` super calls.
4) Note: makes a chage for `method_entry_cref` to use `const`.
On master the benchmarks showed that `super` is 1.76x slower. Our
changes improved the performance so that it is now only 1.36x slower.
Benchmark IPS:
```
Warming up --------------------------------------
super 244.918k i/100ms
method call 383.007k i/100ms
Calculating -------------------------------------
super 2.280M (± 6.7%) i/s - 11.511M in 5.071758s
method call 3.834M (± 4.9%) i/s - 19.150M in 5.008444s
Comparison:
method call: 3833648.3 i/s
super: 2279837.9 i/s - 1.68x (± 0.00) slower
```
With changes:
```
Warming up --------------------------------------
super 308.777k i/100ms
method call 375.051k i/100ms
Calculating -------------------------------------
super 2.951M (± 5.4%) i/s - 14.821M in 5.039592s
method call 3.551M (± 4.9%) i/s - 18.002M in 5.081695s
Comparison:
method call: 3551372.7 i/s
super: 2950557.9 i/s - 1.20x (± 0.00) slower
```
Ruby VM benchmarks also showed an improvement:
Existing `vm_super` benchmark`.
```
$ make benchmark ITEM=vm_super
| |compare-ruby|built-ruby|
|:---------|-----------:|---------:|
|vm_super | 21.555M| 37.819M|
| | -| 1.75x|
```
New `vm_iclass_super` benchmark:
```
$ make benchmark ITEM=vm_iclass_super
| |compare-ruby|built-ruby|
|:----------------|-----------:|---------:|
|vm_iclass_super | 1.669M| 3.683M|
| | -| 2.21x|
```
This is the benchmark script used for the benchmark-ips benchmarks:
```ruby
require "benchmark/ips"
class Foo
def zuper; end
def top; end
last_method = "top"
("A".."M").each do |module_name|
eval <<-EOM
module #{module_name}
def zuper; super; end
def #{module_name.downcase}
#{last_method}
end
end
prepend #{module_name}
EOM
last_method = module_name.downcase
end
end
foo = Foo.new
Benchmark.ips do |x|
x.report "super" do
foo.zuper
end
x.report "method call" do
foo.m
end
x.compare!
end
```
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
Co-authored-by: John Hawthorn <john@hawthorn.email>
`encoding` can be not only an encoding name, but also an Encoding object.
```
s = String.new('foo', encoding: Encoding::US_ASCII)
s.encoding # => #<Encoding:US-ASCII>
```