Before this commit, we were mixing a lot of concerns with the prism
compile between RubyVM::InstructionSequence and the general entry
points to the prism parser/compiler.
This commit makes all of the various prism-related APIs mirror
their corresponding APIs in the existing parser/compiler. This means
we now have the correct frame naming, and it's much easier to follow
where the logic actually flows. Furthermore this consolidates a lot
of the prism initialization, making it easier to see where we could
potentially be raising errors.
[Bug #20071]
Currently Ruby crashes when the --parser=prism flag is used either with
no input, or with input that is being redirected from stdin. So all of
the following will crash
ruby --parser=prism
ruby --parser=prism < test_code.rb
cat test_code.rb | ruby --parser=prism
This commit checks whether the input is assumed to be from stdin, and
then processes that as a file.
This will fix the second and third case above, but will cause a slight
behavioural changes for the first case - Ruby will treat stdin as an
empty file in this case and exit, rather than waiting for data to be
piped into stdin.
when the RUBY_FREE_ON_SHUTDOWN environment variable is set, manually free memory at shutdown.
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-authored-by: Peter Zhu <peter@peterzhu.ca>
If `RUBY_MN_THREADS=1` is given, this patch shows `+MN` in
`RUBY_DESCRIPTION` like:
```
$ RUBY_MN_THREADS=1 ./miniruby --yjit -v
ruby 3.3.0dev (2023-10-17T04:10:14Z master 908f8fffa2) +YJIT +MN [x86_64-linux]
```
Before this patch, a warning is displayed if `$VERBOSE` is given.
However it can make troubles with tests (with `$VERBOSE`), do not
show any warning with a MN threads configuration.
This patch introduce M:N thread scheduler for Ractor system.
In general, M:N thread scheduler employs N native threads (OS threads)
to manage M user-level threads (Ruby threads in this case).
On the Ruby interpreter, 1 native thread is provided for 1 Ractor
and all Ruby threads are managed by the native thread.
From Ruby 1.9, the interpreter uses 1:1 thread scheduler which means
1 Ruby thread has 1 native thread. M:N scheduler change this strategy.
Because of compatibility issue (and stableness issue of the implementation)
main Ractor doesn't use M:N scheduler on default. On the other words,
threads on the main Ractor will be managed with 1:1 thread scheduler.
There are additional settings by environment variables:
`RUBY_MN_THREADS=1` enables M:N thread scheduler on the main ractor.
Note that non-main ractors use the M:N scheduler without this
configuration. With this configuration, single ractor applications
run threads on M:1 thread scheduler (green threads, user-level threads).
`RUBY_MAX_CPU=n` specifies maximum number of native threads for
M:N scheduler (default: 8).
This patch will be reverted soon if non-easy issues are found.
[Bug #19842]
This commit changes RUBY_GC_HEAP_INIT_SIZE_{40,80,160,320,640}_SLOTS to
RUBY_GC_HEAP_{0,1,2,3,4}_INIT_SLOTS. This is easier to use because the
user does not need to determine the slot sizes (which can vary between
32 and 64 bit systems). They now just use the heap names
(`GC.stat_heap.keys`).
In general, if the same option specifying a single value is given
multiple times at the same level, the last one overrides the earlier
ones, unless prohibited.
There’s no reason to prevent RUBYOPT from controlling the backtrace
limit. In fact, Matz said [0] he was expecting this to be possible.
[0] https://bugs.ruby-lang.org/issues/8661#note-27
Kevin Newton
Matt Valentine-House
Nobuyoshi Nakada
Takashi Kokubun
HParker
Aaron Patterson
Adam Hess
Jemma Issroff
Koichi Sasada
Maxime Chevalier-Boisvert
Peter Zhu
Jeremy Evans
Benoit Daloze
Tom Stuart