20201112T123004Z.fail.html.gz
```
1)
File.utime allows Time instances in the far future to set mtime and
atime (but some filesystems limit it up to 2446-05-10) FAILED
Expected [559444, 2446].include? 2038
to be truthy but was false
/home/chkbuild/chkbuild/tmp/build/20201112T123004Z/ruby/spec/ruby/core/file/utime_spec.rb:80:in
`block (4 levels) in <top (required)>'
/home/chkbuild/chkbuild/tmp/build/20201112T123004Z/ruby/spec/ruby/core/file/utime_spec.rb:3:in
`<top (required)>'
```
```
$ touch foo
$ ./miniruby -e 'time = Time.at(1<<44); File.utime(time, time, "foo")'
$ ls -l foo
-rw-r--r--. 1 mame wheel 0 Jan 19 2038 foo
```
close_incoming by antoher ractor means there is no other messages
will be sent to the ractor, so Ractor.receive will block forever,
and it should raise and stop.
close_outgoing by antoher ractor means, ... I don't have good idea
to use it. It can be a private method.
Ractor#close calls both, but it does not make sense to call
different purpose methods, so I remove it.
The timer function used on windows system set timer interrupt
flag of current main ractor's executing ec and thread can detect
the end of time slice. However, to set all ec->interrupt_flag for
all running ractors, it is requires to synchronize with other ractors.
However, timer thread can not acquire the ractor-wide lock because
of some limitation.
To solve this issue, this patch introduces USE_VM_CLOCK compile option
to introduce rb_vm_t::clock. This clock will be incremented by the
timer thread and each thread can check the incrementing by comparison
with previous checked clock. At last, on windows platform this patch
introduces some overhead, but I think there is no critical performance
issue because of this modification.
Racc calls `Array#sort!` to build a state transition table. As
`Array#sort!` is not a stable sort, the output may differ depending upon
the environment.
This changeset makes the sort stable manually, and updates all
expectation files.
This benchmark demonstrates the performance of setting an instance
variable when the type of object is constantly changing. This benchmark
should give us an idea of the performance of ivar setting in a
polymorphic environment
This commit adds a debug counter for the case where the inline cache
*missed* but the ivar index table has an entry for that ivar. This is a
case where a polymorphic cache could help
iv tables cannot shrink. If the inline cache was ever set, then there
must be an entry for the instance variable in the iv table. Just set
the iv list on the object to be equal to the iv index table size, then
set the iv.
When the inline cache is written, the iv table will contain an entry for
the instance variable. If we get an inline cache hit, then we know the
iv table must contain a value for the index written to the inline cache.
If the index in the inline cache is larger than the list on the object,
but *smaller* than the iv index table on the class, then we can just
eagerly allocate the iv list to be the same size as the iv index table.
This avoids duplicate work of checking frozen as well as looking up the
index for the particular instance variable name.
