summaryrefslogtreecommitdiff
path: root/vm_core.h
AgeCommit message (Collapse)Author
2019-12-21Kernel#lambda: return forwarded block as non-lambda procAlan Wu
Before this commit, Kernel#lambda can't tell the difference between a directly passed literal block and one passed with an ampersand. A block passed with an ampersand is semantically speaking already a non-lambda proc. When Kernel#lambda receives a non-lambda proc, it should simply return it. Implementation wise, when the VM calls a method with a literal block, it places the code for the block on the calling control frame and passes a pointer (block handler) to the callee. Before this commit, the VM forwards block arguments by simply forwarding the block handler, which leaves the slot for block code unused when a control frame forwards its block argument. I use the vacant space to indicate that a frame has forwarded its block argument and inspect that in Kernel#lambda to detect forwarded blocks. This is a very ad-hoc solution and relies *heavily* on the way block passing works in the VM. However, it's the most self-contained solution I have. [Bug #15620] Notes: Merged: https://github.com/ruby/ruby/pull/2289
2019-12-18delete rb_vm_call()卜部昌平
Nobody uses it any longer.
2019-12-17disable assertion.Koichi Sasada
This assertion is not needed because we found the bug. ba11a74745.
2019-12-16Kernel#abort without arguments should print error infoNobuyoshi Nakada
[Bug #16424] Notes: Merged: https://github.com/ruby/ruby/pull/2754
2019-12-10vm_core.h (iseq_unique_id): prefer uintptr_t instead of unsigned longYusuke Endoh
It produced a warning about type cast in LLP64 (i.e., windows).
2019-12-09vm_args.c (rb_warn_check): Use iseq_unique_id instead of its pointerYusuke Endoh
(This is the second try of 036bc1da6c6c9b0fa9b7f5968d897a9554dd770e.) If iseq is GC'ed, the pointer of iseq may be reused, which may hide a deprecation warning of keyword argument change. http://ci.rvm.jp/results/trunk-test1@phosphorus-docker/2474221 ``` 1) Failure: TestKeywordArguments#test_explicit_super_kwsplat [/tmp/ruby/v2/src/trunk-test1/test/ruby/test_keyword.rb:549]: --- expected +++ actual @@ -1 +1 @@ -/The keyword argument is passed as the last hash parameter.* for `m'/m +"" ``` This change ad-hocly adds iseq_unique_id for each iseq, and use it instead of iseq pointer. This covers the case where caller is GC'ed. Still, the case where callee is GC'ed, is not covered. But anyway, it is very rare that iseq is GC'ed. Even when it occurs, it just hides some warnings. It's no big deal.
2019-12-09Revert "vm_args.c (rb_warn_check): Use iseq_unique_id instead of its pointer"Yusuke Endoh
This reverts commit 036bc1da6c6c9b0fa9b7f5968d897a9554dd770e. This caused a failure on iseq_binary mode. http://ci.rvm.jp/results/trunk-iseq_binary@silicon-docker/2474587 Numbering iseqs is not trivial due to dump/load.
2019-12-09vm_args.c (rb_warn_check): Use iseq_unique_id instead of its pointerYusuke Endoh
If iseq is GC'ed, the pointer of iseq may be reused, which may hide a deprecation warning of keyword argument change. http://ci.rvm.jp/results/trunk-test1@phosphorus-docker/2474221 ``` 1) Failure: TestKeywordArguments#test_explicit_super_kwsplat [/tmp/ruby/v2/src/trunk-test1/test/ruby/test_keyword.rb:549]: --- expected +++ actual @@ -1 +1 @@ -/The keyword argument is passed as the last hash parameter.* for `m'/m +"" ``` This change ad-hocly adds iseq_unique_id for each iseq, and use it instead of iseq pointer. This covers the case where caller is GC'ed. Still, the case where callee is GC'ed, is not covered. But anyway, it is very rare that iseq is GC'ed. Even when it occurs, it just hides some warnings. It's no big deal.
2019-12-05Introduce an "Inline IVAR cache" structAaron Patterson
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)
2019-11-19make functions static卜部昌平
These functions are used from within a compilation unit so we can make them static, for better binary size. This changeset reduces the size of generated ruby binary from 26,590,128 bytes to 26,584,472 bytes on my macihne. Notes: Merged: https://github.com/ruby/ruby/pull/2682
2019-11-18Warn on access/modify of $SAFE, and remove effects of modifying $SAFEJeremy Evans
This removes the security features added by $SAFE = 1, and warns for access or modification of $SAFE from Ruby-level, as well as warning when calling all public C functions related to $SAFE. This modifies some internal functions that took a safe level argument to no longer take the argument. rb_require_safe now warns, rb_require_string has been added as a version that takes a VALUE and does not warn. One public C function that still takes a safe level argument and that this doesn't warn for is rb_eval_cmd. We may want to consider adding an alternative method that does not take a safe level argument, and warn for rb_eval_cmd. Notes: Merged: https://github.com/ruby/ruby/pull/2476
2019-11-14delete unused functions卜部昌平
Looking at the list of symbols inside of libruby-static.a, I found hundreds of functions that are defined, but used from nowhere. There can be reasons for each of them (e.g. some functions are specific to some platform, some are useful when debugging, etc). However it seems the functions deleted here exist for no reason. This changeset reduces the size of ruby binary from 26,671,456 bytes to 26,592,864 bytes on my machine. Notes: Merged: https://github.com/ruby/ruby/pull/2677
2019-11-11__builtin_inline!Koichi Sasada
Add an experimental `__builtin_inline!(c_expression)` special intrinsic which run a C code snippet. In `c_expression`, you can access the following variables: * ec (rb_execution_context_t *) * self (const VALUE) * local variables (const VALUE) Not that you can read these variables, but you can not write them. You need to return from this expression and return value will be a result of __builtin_inline!(). Examples: `def foo(x) __builtin_inline!('return rb_p(x);'); end` calls `p(x)`. `def double(x) __builtin_inline!('return INT2NUM(NUM2INT(x) * 2);')` returns x*2.
2019-11-08support builtin features with Ruby and C.Koichi Sasada
Support loading builtin features written in Ruby, which implement with C builtin functions. [Feature #16254] Several features: (1) Load .rb file at boottime with native binary. Now, prelude.rb is loaded at boottime. However, this file is contained into the interpreter as a text format and we need to compile it. This patch contains a feature to load from binary format. (2) __builtin_func() in Ruby call func() written in C. In Ruby file, we can write `__builtin_func()` like method call. However this is not a method call, but special syntax to call a function `func()` written in C. C functions should be defined in a file (same compile unit) which load this .rb file. Functions (`func` in above example) should be defined with (a) 1st parameter: rb_execution_context_t *ec (b) rest parameters (0 to 15). (c) VALUE return type. This is very similar requirements for functions used by rb_define_method(), however `rb_execution_context_t *ec` is new requirement. (3) automatic C code generation from .rb files. tool/mk_builtin_loader.rb creates a C code to load .rb files needed by miniruby and ruby command. This script is run by BASERUBY, so *.rb should be written in BASERUBY compatbile syntax. This script load a .rb file and find all of __builtin_ prefix method calls, and generate a part of C code to export functions. tool/mk_builtin_binary.rb creates a C code which contains binary compiled Ruby files needed by ruby command. Notes: Merged: https://github.com/ruby/ruby/pull/2655
2019-10-25enable assertion for debug.Koichi Sasada
http://ci.rvm.jp/results/trunk-vm-asserts@silicon-docker/2340856
2019-10-25more on struct rb_call_data卜部昌平
Replacing adjacent struct rb_call_info and struct rb_call_cache into a struct rb_call_data.
2019-10-24Combine call info and cache to speed up method invocationAlan Wu
To perform a regular method call, the VM needs two structs, `rb_call_info` and `rb_call_cache`. At the moment, we allocate these two structures in separate buffers. In the worst case, the CPU needs to read 4 cache lines to complete a method call. Putting the two structures together reduces the maximum number of cache line reads to 2. Combining the structures also saves 8 bytes per call site as the current layout uses separate two pointers for the call info and the call cache. This saves about 2 MiB on Discourse. This change improves the Optcarrot benchmark at least 3%. For more details, see attached bugs.ruby-lang.org ticket. Complications: - A new instruction attribute `comptime_sp_inc` is introduced to calculate SP increase at compile time without using call caches. At compile time, a `TS_CALLDATA` operand points to a call info struct, but at runtime, the same operand points to a call data struct. Instruction that explicitly define `sp_inc` also need to define `comptime_sp_inc`. - MJIT code for copying call cache becomes slightly more complicated. - This changes the bytecode format, which might break existing tools. [Misc #16258] Notes: Merged: https://github.com/ruby/ruby/pull/2564
2019-10-09Share ruby_sighandler_t definitionNobuyoshi Nakada
2019-10-09signal.c: save the original sighandlers for fatal signalsYusuke Endoh
On Android, a signal handler that is not SIG_DFL is set by default for SIGSEGV. Ruby's install_sighandler inserts Ruby's handler only when the signal has no handler, so it does not insert Ruby's SEGV report handler, which caused some test failures. This changeset forces to install Ruby's handler for some fatal signals (sigbus, sigsegv, and sigill). They keep the original handlers, and call them when the interpreter receives the signals.
2019-10-09error.c (rb_bug_for_fatal_signal): renamed from rb_bug_contextYusuke Endoh
Just refactoring. The name "rb_bug_context" is completely unclear for me. (Can you see that "context" means "machine register context"?) The context is available only when a fatal signal (sigbus, sigsegv, or sigill) is received; in fact, the function is used only for fatal signals. So, I think the name should be changed.
2019-10-04iseq.c (rb_iseq_compile_on_base): RemovedYusuke Endoh
ko1 cannot remember why he introduced the function. And it is not used. After it is removed, the argument "base_block" of rb_iseq_compile_with_option is always zero.
2019-10-03Revert https://github.com/ruby/ruby/pull/2486卜部昌平
This reverts commits: 10d6a3aca7 8ba48c1b85 fba8627dc1 dd883de5ba 6c6a25feca 167e6b48f1 7cb96d41a5 3207979278 595b3c4fdd 1521f7cf89 c11c5e69ac cf33608203 3632a812c0 f56506be0d 86427a3219 . The reason for the revert is that we observe ABA problem around inline method cache. When a cache misshits, we search for a method entry. And if the entry is identical to what was cached before, we reuse the cache. But the commits we are reverting here introduced situations where a method entry is freed, then the identical memory region is used for another method entry. An inline method cache cannot detect that ABA. Here is a code that reproduce such situation: ```ruby require 'prime' class << Integer alias org_sqrt sqrt def sqrt(n) raise end GC.stress = true Prime.each(7*37){} rescue nil # <- Here we populate CC class << Object.new; end # These adjacent remove-then-alias maneuver # frees a method entry, then immediately # reuses it for another. remove_method :sqrt alias sqrt org_sqrt end Prime.each(7*37).to_a # <- SEGV ```
2019-09-30refactor constify most of rb_method_definition_t卜部昌平
Most (if not all) of the fields of rb_method_definition_t are never meant to be modified once after they are stored. Marking them const makes it possible for compilers to warn on unintended modifications. Notes: Merged: https://github.com/ruby/ruby/pull/2486
2019-09-29Remove VM_NO_KEYWORDS, replace with RB_NO_KEYWORDSJeremy Evans
VM_NO_KEYWORDS was introduced first in vm_core.h, but it is best to only use a single definition for this.
2019-09-26Fix keyword argument separation issues in Thread.newJeremy Evans
Notes: Merged: https://github.com/ruby/ruby/pull/2484
2019-09-25Add Module#ruby2_keywords for passing keywords through regular argument splatsJeremy Evans
This approach uses a flag bit on the final hash object in the regular splat, as opposed to a previous approach that used a VM frame flag. The hash flag approach is less invasive, and handles some cases that the VM frame flag approach does not, such as saving the argument splat array and splatting it later: ruby2_keywords def foo(*args) @args = args bar end def bar baz(*@args) end def baz(*args, **kw) [args, kw] end foo(a:1) #=> [[], {a: 1}] foo({a: 1}, **{}) #=> [[{a: 1}], {}] foo({a: 1}) #=> 2.7: [[], {a: 1}] # and warning foo({a: 1}) #=> 3.0: [[{a: 1}], {}] It doesn't handle some cases that the VM frame flag handles, such as when the final hash object is replaced using Hash#merge, but those cases are probably less common and are unlikely to properly support keyword argument separation. Use ruby2_keywords to handle argument delegation in the delegate library. Notes: Merged: https://github.com/ruby/ruby/pull/2477
2019-09-21typedef rb_jmpbuf_t to void *[5] if __builtin_setjmp is usedFangrui Song
The built-in version operates on a buffer of 5 words, much smaller than the size of jmp_buf defined in libc. Note, powerpc requires 5 words, while arm and x86_64 just require 3. Notes: Merged: https://github.com/ruby/ruby/pull/2471
2019-09-13Moved ruby_node_name declaration to node.hNobuyoshi Nakada
2019-09-06Convert keyword argument to required positional hash argument for Class#new, ↵Jeremy Evans
Method#call, UnboundMethod#bind_call Also add keyword argument separation warnings for Class#new and Method#call. To allow for keyword argument to required positional hash converstion in cfuncs, add a vm frame flag indicating the cfunc was called with an empty keyword hash (which was removed before calling the cfunc). The cfunc can check this frame flag and add back an empty hash if it is passing its arguments to another Ruby method. Add rb_empty_keyword_given_p function for checking if called with an empty keyword hash, and rb_add_empty_keyword for adding back an empty hash to argv. All of this empty keyword argument support is only for 2.7. It will be removed in 3.0 as Ruby 3 will not convert empty keyword arguments to required positional hash arguments. Comment all of the relevent code to make it obvious this is expected to be removed. Add rb_funcallv_kw as an public C-API function, just like rb_funcallv but with a keyword flag. This is used by rb_obj_call_init (internals of Class#new). This also required expected call_type enum with CALL_FCALL_KW, similar to the recent addition of CALL_PUBLIC_KW. Add rb_vm_call_kw as a internal function, used by call_method_data (internals of Method#call and UnboundMethod#bind_call). Add tests for UnboundMethod#bind_call keyword handling. Notes: Merged: https://github.com/ruby/ruby/pull/2432
2019-09-05Add VM_NO_KEYWORDSJeremy Evans
I think this is easier to read than using literal 0 with comments in every case where it is used.
2019-09-05Propagate kw_splat informationYusuke Endoh
The kw_splat flag is whether the original call passes keyword or not. Some types of methods (e.g., bmethod and sym_proc) drops the information. This change tries to propagate the flag to the final callee, as far as I can.
2019-09-05hide rb_funcallv_with_cc from public卜部昌平
Requested by ko1. Also, because now that this function is internal use only, why not just directly use struct rb_call_cache to purge the ZALLOC.
2019-09-03Merge pull request #2422 from jeremyevans/rb_keyword_given_pJeremy Evans
Add rb_keyword_given_p to the C-API Notes: Merged-By: jeremyevans <code@jeremyevans.net>
2019-09-03Make the rb_vmdebug_debug_print_post declarationTakashi Kokubun
consistent with the definition
2019-08-30Support **nil syntax for specifying a method does not accept keyword argumentsJeremy Evans
This syntax means the method should be treated as a method that uses keyword arguments, but no specific keyword arguments are supported, and therefore calling the method with keyword arguments will raise an ArgumentError. It is still allowed to double splat an empty hash when calling the method, as that does not pass any keyword arguments. Notes: Merged: https://github.com/ruby/ruby/pull/2395
2019-08-27rb_thread_create now free from ANYARGS卜部昌平
After 5e86b005c0f2ef30df2f9906c7e2f3abefe286a2, I now think ANYARGS is dangerous and should be extinct. This commit deletes ANYARGS from rb_thread_create, which seems very safe to do.
2019-08-27rb_ensure now free from ANYARGS卜部昌平
After 5e86b005c0f2ef30df2f9906c7e2f3abefe286a2, I now think ANYARGS is dangerous and should be extinct. This commit deletes ANYARGS from rb_ensure, which also revealed many arity / type mismatches.
2019-08-27decouple compile.c usage of imemo_ifunc卜部昌平
After 5e86b005c0f2ef30df2f9906c7e2f3abefe286a2, I now think ANYARGS is dangerous and should be extinct. This commit deletes ANYARGS from struct vm_ifunc, but in doing so we also have to decouple the usage of this struct in compile.c, which (I think) is an abuse of ANYARGS.
2019-08-17Make VM_DEBUG_VERIFY_METHOD_CACHE derived from VMDEBUGNobuyoshi Nakada
VM_DEBUG_MODE has been used only here.
2019-08-13Renamed ruby_finalize_{0,1}Nobuyoshi Nakada
And pass rb_execution_context_t as an argument.
2019-08-02Revert "Revert "Add a specialized instruction for `.nil?` calls""Yusuke Endoh
This reverts commit a0980f2446c0db735b8ffeb37e241370c458a626. Retry for macOS Mojave.
2019-08-02Revert "Add a specialized instruction for `.nil?` calls"Yusuke Endoh
This reverts commit 9faef3113fb4331524b81ba73005ba13fa0ef6c6. It seemed to cause a failure on macOS Mojave, though I'm unsure how. https://rubyci.org/logs/rubyci.s3.amazonaws.com/osx1014/ruby-master/log/20190802T034503Z.fail.html.gz This tentative revert is to check if the issue is actually caused by the change or not.
2019-07-31Add a specialized instruction for `.nil?` callsAaron Patterson
This commit adds a specialized instruction for called to `.nil?`. It is about 27% faster than master in the case where the object is nil or not nil. In the case where an object implements `nil?`, I think it may be slightly slower. Here is a benchmark: ```ruby require "benchmark/ips" class Niller def nil?; true; end end not_nil = Object.new xnil = nil niller = Niller.new Benchmark.ips do |x| x.report("nil?") { xnil.nil? } x.report("not nil") { not_nil.nil? } x.report("niller") { niller.nil? } end ``` On Ruby master: ``` [aaron@TC ~/g/ruby (master)]$ ./ruby compil.rb Warming up -------------------------------------- nil? 429.195k i/100ms not nil 437.889k i/100ms niller 437.935k i/100ms Calculating ------------------------------------- nil? 20.166M (± 8.1%) i/s - 100.002M in 5.002794s not nil 20.046M (± 7.6%) i/s - 99.839M in 5.020086s niller 22.467M (± 6.1%) i/s - 112.111M in 5.013817s [aaron@TC ~/g/ruby (master)]$ ./ruby compil.rb Warming up -------------------------------------- nil? 449.660k i/100ms not nil 433.836k i/100ms niller 443.073k i/100ms Calculating ------------------------------------- nil? 19.997M (± 8.8%) i/s - 99.375M in 5.020458s not nil 20.529M (± 7.0%) i/s - 102.385M in 5.020689s niller 21.796M (± 8.0%) i/s - 108.110M in 5.002300s [aaron@TC ~/g/ruby (master)]$ ./ruby compil.rb Warming up -------------------------------------- nil? 402.119k i/100ms not nil 438.968k i/100ms niller 398.226k i/100ms Calculating ------------------------------------- nil? 20.050M (±12.2%) i/s - 98.519M in 5.008817s not nil 20.614M (± 8.0%) i/s - 102.280M in 5.004531s niller 22.223M (± 8.8%) i/s - 110.309M in 5.013106s ``` On this branch: ``` [aaron@TC ~/g/ruby (specialized-nilp)]$ ./ruby compil.rb Warming up -------------------------------------- nil? 468.371k i/100ms not nil 456.517k i/100ms niller 454.981k i/100ms Calculating ------------------------------------- nil? 27.849M (± 7.8%) i/s - 138.169M in 5.001730s not nil 26.417M (± 8.7%) i/s - 131.020M in 5.011674s niller 21.561M (± 7.5%) i/s - 107.376M in 5.018113s [aaron@TC ~/g/ruby (specialized-nilp)]$ ./ruby compil.rb Warming up -------------------------------------- nil? 477.259k i/100ms not nil 428.712k i/100ms niller 446.109k i/100ms Calculating ------------------------------------- nil? 28.071M (± 7.3%) i/s - 139.837M in 5.016590s not nil 25.789M (±12.9%) i/s - 126.470M in 5.011144s niller 20.002M (±12.2%) i/s - 98.144M in 5.001737s [aaron@TC ~/g/ruby (specialized-nilp)]$ ./ruby compil.rb Warming up -------------------------------------- nil? 467.676k i/100ms not nil 445.791k i/100ms niller 415.024k i/100ms Calculating ------------------------------------- nil? 26.907M (± 8.0%) i/s - 133.755M in 5.013915s not nil 25.319M (± 7.9%) i/s - 125.713M in 5.007758s niller 19.569M (±11.8%) i/s - 96.286M in 5.008533s ``` Co-Authored-By: Ashe Connor <kivikakk@github.com>
2019-07-15respect RUBY_DEBUG.Koichi Sasada
see RUBY_DEBUG for each debug options.
2019-07-14Make export declaration place more consistentTakashi Kokubun
2019-06-20Ensure that vm_stack is cleared in `thread_cleanup_func_before_exec`.Samuel Williams
If `vm_stack` is left dangling in a forked process, the gc attempts to scan it, but it is invalid and will cause a segfault. Therefore, we clear it before forking. In order to simplify this, `rb_ec_clear_vm_stack` was introduced.
2019-06-20Revert failed attempt at fixing invalid usage of vm_stack.Samuel Williams
2019-06-20Ensure `vm_stack` is cleared after fork.Samuel Williams
2019-06-19Remove IA64 support.Samuel Williams
2019-06-19Use shared implementation of `rb_ec_initialize_vm_stack`.Samuel Williams