when we already check ROBJECT_NUMIV(self) is larger than
ROBJECT_EMBED_LEN_MAX at the beginning of the method, because the number
of instance variables for the same object doesn't decrease.
```
$ benchmark-driver -v --rbenv 'before --jit;after --jit' --repeat-count=4 --alternate --output=all benchmark_3000.yml
before --jit: ruby 3.0.0dev (2020-12-23T06:32:19Z master dbb4f19969) +JIT [x86_64-linux]
after --jit: ruby 3.0.0dev (2020-12-23T07:45:42Z master 95e866c098) +JIT [x86_64-linux]
last_commit=Skip checking ROBJECT_EMBED
Calculating -------------------------------------
before --jit after --jit
Optcarrot 3000 frames 102.34091772397872 102.77738408379015 fps
103.37784821624231 105.46530219076179
104.39567016876369 106.43712452152215
105.31782092252713 106.54986150067481
```
iv_index_tbl manages instance variable indexes (ID -> index).
This data structure should be synchronized with other ractors
so introduce some VM locks.
This patch also introduced atomic ivar cache used by
set/getinlinecache instructions. To make updating ivar cache (IVC),
we changed iv_index_tbl data structure to manage (ID -> entry)
and an entry points serial and index. IVC points to this entry so
that cache update becomes atomically.
generic_ivtbl is a process global table to maintain instance variables
for non T_OBJECT/T_CLASS/... objects. So we need to protect them
for multi-Ractor exection.
Hint: we can make them Ractor local for unshareable objects, but
now it is premature optimization.
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.
This commit introduces an "inline ivar cache" struct. The reason we
need this is so compaction can differentiate from an ivar cache and a
regular inline cache. Regular inline caches contain references to
`VALUE` and ivar caches just contain references to the ivar index. With
this new struct we can easily update references for inline caches (but
not inline var caches as they just contain an int)
I'm writing `//` comments in newer MJIT code after C99 enablement
(because I write 1-line comments more often than multi-line comments
and `//` requires fewer chars on 1-line) and then they are mixed
with `/* */` now.
For consistency and to avoid the conversion in future changes, let me
finish the rewrite in MJIT-related code.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67533 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
cfp->bp was (re-)introduced by Kokubun san, but VM doesn't use it
because I (ko1) want to remove it in a future. But using it make
leave instruction fast because of sp consisntency check.
So now VM uses cfp->bp.
To use cfp->bp, I checked the value and I found that it is not a
"initial value of sp" but a "initial value of ep". Fix this problem
and fix all bp references (this is why bp is renamed to bp_).
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67342 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I assumed somehow this check was not needed, but it did need.
By canceling this instead of just warning here, we didn't lose the
current performance so much.
test_jit.rb: test the case that reproduces SEGV by that.
TestGemStreamUI.rb: delete. This test on --jit-wait is fixed.
=== Optcarrot Benchmark ===
$ benchmark-driver benchmark.yml --rbenv 'before::before --disable-gems --jit;after::after --disable-gems --jit' -v --repeat-count 24
before: ruby 2.6.0dev (2018-10-24 trunk 65355) +JIT [x86_64-linux]
after: ruby 2.6.0dev (2018-10-24 trunk 65355) +JIT [x86_64-linux]
last_commit=_mjit_compile_ivar.erb: cancel on undefined ivar
Calculating -------------------------------------
before after
Optcarrot Lan_Master.nes 85.344 84.849 fps
Comparison:
Optcarrot Lan_Master.nes
before: 85.3 fps
after: 84.8 fps - 1.01x slower
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65356 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
on VM_CHECK_INTS. Letting MJIT worker directly see inline cache which
may be being updated could result in inconsistent IC index and serial.
mjit_worker.c: request the copy job after dequeue, and receive the
result synchronously.
tool/ruby_vm/views/_mjit_compile_ivar.erb: use the copied IC
mjit_compile.c: change the interface to pass is_entries
mjit.h: ditto
=== Optcarrot Benchmark ===
Thankfully this didn't have major performance regression.
$ benchmark-driver benchmark.yml --rbenv 'before::before --disable-gems --jit;after::after --disable-gems --jit' -v --repeat-count 24
before: ruby 2.6.0dev (2018-10-21 trunk 65263) +JIT [x86_64-linux]
after: ruby 2.6.0dev (2018-10-21 trunk 65263) +JIT [x86_64-linux]
last_commit=mjit.c: copy inline cache values to MJIT worker
Calculating -------------------------------------
before after
Optcarrot Lan_Master.nes 85.421 85.454 fps
Comparison:
Optcarrot Lan_Master.nes
after: 85.5 fps
before: 85.4 fps - 1.00x slower
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65275 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
We have several options to ensure there's no race condition between main
thread and MJIT thead about IC reference:
1) Give up caching ivar for multiple classes (or multiple versions of the
same class) in the same getinstancevariable (This commit's approach)
2) Allocate new inline cache every time
Other ideas we could think of couldn't eliminate possibilities of race
condition.
In 2, it's memory allocation would be slow and it may trigger JIT
cancellation frequently. So 1 would be fast for both VM and JIT
situations.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65213 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
`ic->ic_value.index` is size_t, not always unsigned long.
See also: 443560810 (L2263)
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65166 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
