| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
* Remove freezestring instruction since this was the only usage for it.
* [Feature #17104]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Just moved "case base" after allocating cache space.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 3a4be429b50062122d1616256de38649464d3146.
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.
|
| | |
|
| |
|
|
|
| |
I'm not necessarily against every goto in general, but jumping into a
branch is definitely a bad idea. Better refactor.
|
| |
|
|
|
| |
I'm not necessarily against every goto in general, but jumping into a
branch is definitely a bad idea. Better refactor.
|
| |
|
|
|
| |
I'm not necessarily against every goto in general, but jumping into a
branch is definitely a bad idea. Better refactor.
|
| |
|
|
|
| |
I'm not necessarily against every goto in general, but jumping into a
branch is definitely a bad idea. Better refactor.
|
| |
|
|
|
| |
I'm not necessarily against every goto in general, but jumping into a
branch is definitely a bad idea. Better refactor.
|
| |
|
|
|
| |
I'm not necessarily against every goto in general, but jumping into a
branch is definitely a bad idea. Better refactor.
|
| |
|
|
|
| |
I'm not necessarily against every goto in general, but jumping into a
branch is definitely a bad idea. Better refactor.
|
| |
|
|
|
| |
I'm not necessarily against every goto in general, but jumping into a
branch is definitely a bad idea. Better refactor.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Moved this hack mark to an argument to `compile_hash`.
> Bad Hack: temporarily mark hash node with flag so
> compile_hash can compile call differently.
|
| |
|
| |
[Feature #15589]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Formerly, branch coverage measurement counters are generated for each
compilation traverse of the AST. However, ensure clause node is
traversed twice; one is for normal-exit case (the resulted bytecode is
embedded in its outer scope), and the other is for exceptional case (the
resulted bytecode is used in catch table). Two branch coverage counters
are generated for the two cases, but it is not desired.
This changeset revamps the internal representation of branch coverage
measurement. Branch coverage counters are generated only at the first
visit of a branch node. Visiting the same node reuses the
already-generated counter, so double counting is avoided.
|
| | |
|
| | |
|
| |
|
|
| |
instead of maros. Just refactoring.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes:
```ruby
args = [1, 2, -> {}]; foo(*args, &args.pop)
```
call `foo` with 1, 2, and the lambda, in addition to passing the
lambda as a block. This is different from the previous behavior,
which passed the lambda as a block but not as a regular argument,
which goes against the expected left-to-right evaluation order.
This is how Ruby already compiled arguments if using leading
arguments, trailing arguments, or keywords in the same call.
This works by disabling the optimization that skipped duplicating
the array during the splat (splatarray instruction argument
switches from false to true). In the above example, the splat
call duplicates the array. I've tested and cases where a
local variable or symbol are used do not duplicate the array,
so I don't expect this to decrease the performance of most Ruby
programs. However, programs such as:
```ruby
foo(*args, &bar)
```
could see a decrease in performance, if `bar` is a method call
and not a local variable.
This is not a perfect solution, there are ways to get around
this:
```ruby
args = Struct.new(:a).new([:x, :y])
def args.to_a; a; end
def args.to_proc; a.pop; ->{}; end
foo(*args, &args)
# calls foo with 1 argument (:x)
# not 2 arguments (:x and :y)
```
A perfect solution would require completely disabling the
optimization.
Fixes [Bug #16504]
Fixes [Bug #16500]
|
| | |
|
| |
|
|
|
| |
This reverts commit 19cabe8b09d92d033c244f32ff622b8e513375f1,
which didn't support tool/lib/iseq_loader_checker.rb.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
These crashes are due to alignment issues, casting ADJUST to INSN
and then accessing after the end of the ADJUST. These patches
come from Stefan Sperling <stsp@apache.org>, who reported the
issue.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Create a wrapper object first, then buffer allocation which can
fail.
|
