| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Objects with the same shape must always have the same "embeddedness"
(either embedded or heap allocated) because YJIT assumes so. However,
using remove_instance_variable, it's possible that some objects are
embedded and some are heap allocated because it does not re-embed heap
allocated objects.
This commit changes remove_instance_variable to re-embed Object
instance variables when it becomes small enough.
|
|
|
|
| |
This reverts commit 9b76c7fc89460ed8e9be40e4037c1d68395c0f6d.
|
|
|
|
|
|
|
|
|
|
| |
Enable Prism using either --prism
ruby --prism test.rb
or via env var
RUBY_PRISM=1 ruby test.rb
|
| |
|
|
|
|
| |
https://github.com/ruby/prism/commit/ce4c67fb3a
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Too complex classes use a hash table to store ivs, and should always pin
their IVs. We shouldn't touch those classes in compaction.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This reverts commit 1d5598fe0d3470e7cab06a756d40a9221fcd501b.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During the build, Ruby has special logic to serialize its own builtin
module to disk using the binary iseq format during the build (I assume
for speed so it doesn't have to parse builtin every time it starts
up).
However, since iseq format is architecture-specific, when building on
x86_64 for universal x86_64 + arm64, the serialized builtin module is
written with the x86_64 architecture of the build machine, which fails
this check whenever ruby imports the builtin module on arm64:
https://github.com/ruby/ruby/blob/1fdaa0666086529b3aae2d509a2e71c4247c3a12/compile.c#L13243
Thankfully, there's logic to disable this feature for cross-compiled builds:
https://github.com/ruby/ruby/blob/1fdaa0666086529b3aae2d509a2e71c4247c3a12/builtin.c#L6
This disables the iseq logic for universal builds as well.
Fixes [Bug #18286]
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Follow up: https://github.com/ruby/lrama/pull/139
|
|
|
|
| |
Not to affect other tools invoked as child processes.
|
|
|
|
|
|
|
| |
It's an estimator for application size and could be used as a
compilation heuristic later.
Co-authored-by: Maxime Chevalier-Boisvert <maxime.chevalierboisvert@shopify.com>
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
|
|
|
|
| |
So that the tests can run without updating other than the programs.
|
| |
|
|
|
|
|
|
| |
`-d` option is basically same with `-h` (`--header`).
The difference is `-h` accept header file name.
Therefore remove `-d` option.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
It does not need to be an absolute path.
|
|
|
|
|
| |
GNU Make prior to 4.4 just ignores the prerequisites, and runs
everything in serial.
|
| |
|
|
|
|
| |
And add special treats only for old GNU make.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add yarp/yarp_compiler.c as stencil for compiling YARP
This commit adds yarp/yarp_compiler.c, and changes the sync script
to ensure that yarp/yarp_compiler.c will not get overwritten
* [Misc #119772] Create and expose RubyVM::InstructionSequence.compile_yarp
This commit creates the stencil for a compile_yarp function, which
we will continue to fill out. It allows us to check the output
of compiled YARP code against compiled code without using YARP.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Feature #19783]
This commit adds support for weak references in the GC through the
function `rb_gc_mark_weak`. Unlike strong references, weak references
does not mark the object, but rather lets the GC know that an object
refers to another one. If the child object is freed, the pointer from
the parent object is overwritten with `Qundef`.
Co-Authored-By: Jean Boussier <byroot@ruby-lang.org>
|
| |
|