ruby.git - The Ruby Programming Language

path: root/spec/ruby/library/complex/math/atanh_spec.rb

Age	Commit message (Expand)	Author
2019-09-20	Removed CMath from the ruby repository.	Hiroshi SHIBATA
2018-03-04	Update to ruby/spec@c1b568b	eregon
2017-09-20	Move spec/rubyspec to spec/ruby for consistency	eregon

ved more comprehensively by "runningness" [tracking][1] introduced by Code GC and [delayed deallocation][2]. Having a single counter doesn't fit our current model where code pages that could be touched or not are interleaved, anyway. Just delete the code. [1]: e7c71c6c9271b0c29f210769159090e17128e740 [2]: a0b0365e905e1ac51998ace7e6fc723406a2f157 Notes: Merged-By: maximecb <[email protected]> 2023-03-01YJIT: Use a boxed slice for outgoing branches and cme dependencies (#7409)Takashi Kokubun YJIT: Use a boxed slice for outgoing branches and cme dependencies Notes: Merged-By: maximecb <[email protected]> 2023-02-02Fix typos in YJIT [ci skip]Alan Wu 2023-01-12Enable `clippy` checks for yjit in CI (#7093)Ian Ker-Seymer * Add job to check clippy lints in CI * Address all remaining clippy lints * Check lints on arm64 as well * Apply latest clippy lints * Do not exit 0 on clippy warnings Notes: Merged-By: maximecb <[email protected]> 2022-11-30YJIT: Deallocate `struct Block` to plug memory leaksAlan Wu Previously we essentially never freed block even after invalidation. Their reference count never reached zero for a couple of reasons: 1. `Branch::block` formed a cycle with the block holding the branch 2. Strong count on a branch that has ever contained a stub never reached 0 because we increment the `.clone()` call for `BranchRef::into_raw()` didn't have a matching decrement. It's not safe to immediately deallocate blocks during invalidation since `branch_stub_hit()` can end up running with a branch pointer from an invalidated branch. To plug the leaks, we wait until code GC or global invalidation and deallocate the blocks for iseqs that are definitely not running. Notes: Merged: https://github.com/ruby/ruby/pull/6833 2022-11-30YJIT: Deallocate when assumptions tables are emptyAlan Wu When we run global invalidation for TracePoints or code GC, we clear out all blocks in our assumptions table but we don't deallocate the backing buffers. Let's reclaim some memory during these rare events. Notes: Merged: https://github.com/ruby/ruby/pull/6833 2022-11-22YJIT: Skip padding jumps to side exits on Arm (#6790)Takashi Kokubun YJIT: Skip padding jumps to side exits Co-authored-by: Maxime Chevalier-Boisvert <[email protected]> Co-authored-by: Alan Wu <[email protected]> Co-authored-by: Maxime Chevalier-Boisvert <[email protected]> Co-authored-by: Alan Wu <[email protected]> Notes: Merged-By: maximecb <[email protected]> 2022-11-16YJIT: Stop wrapping CmePtr with CmeDependency (#6747)Takashi Kokubun * YJIT: Stop wrapping CmePtr with CmeDependency * YJIT: Fix an outdated comment [ci skip] Notes: Merged-By: k0kubun <[email protected]> 2022-11-15YJIT: Invalidate redefined methods only through cme (#6734)Takashi Kokubun Co-authored-by: Alan Wu <[email protected]> Co-authored-by: Alan Wu <[email protected]> Notes: Merged-By: k0kubun <[email protected]> 2022-11-08YJIT: Reset dropped_bytes when patching codeAlan Wu We switch to a new page when we detect dropped_bytes flipping from false to true. Previously, when we patch code for invalidation during code gc, we start with the flag being set to true, so we failed to apply patches that straddle pages. We would write out jumps half way and then stop, which left the code corrupted. Reset the flag before patching so we patch across pages properly. Notes: Merged: https://github.com/ruby/ruby/pull/6686 2022-10-18Code clean around unused code for some architectures or features (#6581)Jimmy Miller Notes: Merged-By: maximecb <[email protected]> 2022-10-18Allow passing a Rust closure to rb_iseq_callback (#6575)Takashi Kokubun Notes: Merged-By: k0kubun <[email protected]> 2022-10-14YJIT: Avoid creating payloads for non-JITed ISEQs (#6549)Takashi Kokubun * YJIT: Count freed ISEQs * YJIT: Avoid creating payloads for non-JITed ISEQs Notes: Merged-By: k0kubun <[email protected]> 2022-09-30A bunch of clippy auto fixes for yjit (#6476)Jimmy Miller Notes: Merged-By: maximecb <[email protected]> 2022-09-14YJIT: Implement specialized respond_to? (#6363)John Hawthorn * Add rb_callable_method_entry_or_negative * YJIT: Implement specialized respond_to? This implements a specialized respond_to? in YJIT. * Update yjit/src/codegen.rs Co-authored-by: Maxime Chevalier-Boisvert <[email protected]> Notes: Merged-By: maximecb <[email protected]> 2022-09-01New constant caching insn: opt_getconstant_pathJohn Hawthorn Previously YARV bytecode implemented constant caching by having a pair of instructions, opt_getinlinecache and opt_setinlinecache, wrapping a series of getconstant calls (with putobject providing supporting arguments). This commit replaces that pattern with a new instruction, opt_getconstant_path, handling both getting/setting the inline cache and fetching the constant on a cache miss. This is implemented by storing the full constant path as a null-terminated array of IDs inside of the IC structure. idNULL is used to signal an absolute constant reference. $ ./miniruby --dump=insns -e '::Foo::Bar::Baz' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,13)> (catch: FALSE) 0000 opt_getconstant_path <ic:0 ::Foo::Bar::Baz> ( 1)[Li] 0002 leave The motivation for this is that we had increasingly found the need to disassemble the instructions between the opt_getinlinecache and opt_setinlinecache in order to determine the constant we are fetching, or otherwise store metadata. This disassembly was done: * In opt_setinlinecache, to register the IC against the constant names it is using for granular invalidation. * In rb_iseq_free, to unregister the IC from the invalidation table. * In YJIT to find the position of a opt_getinlinecache instruction to invalidate it when the cache is populated * In YJIT to register the constant names being used for invalidation. With this change we no longe need disassemly for these (in fact rb_iseq_each is now unused), as the list of constant names being referenced is held in the IC. This should also make it possible to make more optimizations in the future. This may also reduce the size of iseqs, as previously each segment required 32 bytes (on 64-bit platforms) for each constant segment. This implementation only stores one ID per-segment. There should be no significant performance change between this and the previous implementation. Previously opt_getinlinecache was a "leaf" instruction, but it included a jump (almost always to a separate cache line). Now opt_getconstant_path is a non-leaf (it may raise/autoload/call const_missing) but it does not jump. These seem to even out. Notes: Merged: https://github.com/ruby/ruby/pull/6187 2022-08-29Use new assembler to support global invalidation on A64Alan Wu Previously, we patched in an x64 JMP even on A64, which resulted in invalid machine code. Use the new assembler to generate a jump instead. Add an assert to make sure patches don't step on each other since it's less clear cut on A64, where the size of the jump varies depending on its placement relative to the target. Fixes a lot of tests that use `set_trace_func` in `test_insns.rb`. PR: https://github.com/Shopify/ruby/pull/379 2022-06-09Add ability to trace exit locations in yjit (#5970)Eileen M. Uchitelle When running with `--yjit-stats` turned on, yjit can inform the user what the most common exits are. While this is useful information it doesn't tell you the source location of the code that exited or what the code that exited looks like. This change intends to fix that. To use the feature, run yjit with the `--yjit-trace-exits` option, which will record the backtrace for every exit that occurs. This functionality requires the stats feature to be turned on. Calling `--yjit-trace-exits` will automatically set the `--yjit-stats` option. Users must call `RubyVM::YJIT.dump_exit_locations(filename)` which will Marshal dump the contents of `RubyVM::YJIT.exit_locations` into a file based on the passed filename. *Example usage:* Given the following script, we write to a file called `concat_array.dump` the results of `RubyVM::YJIT.exit_locations`. ```ruby def concat_array ["t", "r", *x = "u", "e"].join end 1000.times do concat_array end RubyVM::YJIT.dump_exit_locations("concat_array.dump") ``` When we run the file with this branch and the appropriate flags the stacktrace will be recorded. Note Stackprof needs to be installed or you need to point to the library directly. ``` ./ruby --yjit --yjit-call-threshold=1 --yjit-trace-exits -I/Users/eileencodes/open_source/stackprof/lib test.rb ``` We can then read the dump file with Stackprof: ``` ./ruby -I/Users/eileencodes/open_source/stackprof/lib/ /Users/eileencodes/open_source/stackprof/bin/stackprof --text concat_array.dump ``` Results will look similar to the following: ``` ================================== Mode: () Samples: 1817 (0.00% miss rate) GC: 0 (0.00%) ================================== TOTAL (pct) SAMPLES (pct) FRAME 1001 (55.1%) 1001 (55.1%) concatarray 335 (18.4%) 335 (18.4%) invokeblock 178 (9.8%) 178 (9.8%) send 140 (7.7%) 140 (7.7%) opt_getinlinecache ...etc... ``` Simply inspecting the `concatarray` method will give `SOURCE UNAVAILABLE` because the source is insns.def. ``` ./ruby -I/Users/eileencodes/open_source/stackprof/lib/ /Users/eileencodes/open_source/stackprof/bin/stackprof --text concat_array.dump --method concatarray ``` Result: ``` concatarray (nonexistent.def:1) samples: 1001 self (55.1%) / 1001 total (55.1%) callers: 1000 ( 99.9%) Object#concat_array 1 ( 0.1%) Gem.suffixes callees (0 total): code: SOURCE UNAVAILABLE ``` However if we go deeper to the callee we can see the exact source of the `concatarray` exit. ``` ./ruby -I/Users/eileencodes/open_source/stackprof/lib/ /Users/eileencodes/open_source/stackprof/bin/stackprof --text concat_array.dump --method Object#concat_array ``` ``` Object#concat_array (/Users/eileencodes/open_source/rust_ruby/test.rb:1) samples: 0 self (0.0%) / 1000 total (55.0%) callers: 1000 ( 100.0%) block in <main> callees (1000 total): 1000 ( 100.0%) concatarray code: | 1 | def concat_array 1000 (55.0%) | 2 | ["t", "r", *x = "u", "e"].join | 3 | end ``` The `--walk` option is recommended for this feature as it make it easier to traverse the tree of exits. *Goals of this feature:* This feature is meant to give more information when working on YJIT. The idea is that if we know what code is exiting we can decide what areas to prioritize when fixing exits. In some cases this means adding prioritizing avoiding certain exits in yjit. In more complex cases it might mean changing the Ruby code to be more performant when run with yjit. Ultimately the more information we have about what code is exiting AND why, the better we can make yjit. *Known limitations:* * Due to tracing exits, running this on large codebases like Rails can be quite slow. * On complex methods it can still be difficult to pinpoint the exact cause of an exit. * Stackprof is a requirement to to view the backtrace information from the dump file. Co-authored-by: Aaron Patterson <[email protected]> Co-authored-by: Aaron Patterson <[email protected]> Notes: Merged-By: maximecb <[email protected]> 2022-06-06Use bindgen to import Ruby constants wherever possible. (#5943)Noah Gibbs Constants that can't be imported via bindgen should have a comment saying why not. Notes: Merged-By: maximecb <[email protected]> 2022-05-26Use bindgen to import CRuby constants for YARV instruction bytecodesNoah Gibbs (and/or Benchmark CI) Notes: Merged: https://github.com/ruby/ruby/pull/5948 2022-04-29YJIT: Adopt Clippy suggestions we likeAlan Wu This adopts most suggestions that rust-clippy is confident enough to auto apply. The manual changes mostly fix manual if-lets and take opportunities to use the `Default` trait on standard collections. Co-authored-by: Kevin Newton <[email protected]> Co-authored-by: Maxime Chevalier-Boisvert <[email protected]> Notes: Merged: https://github.com/ruby/ruby/pull/5853 2022-04-27Rust YJITAlan Wu In December 2021, we opened an [issue] to solicit feedback regarding the porting of the YJIT codebase from C99 to Rust. There were some reservations, but this project was given the go ahead by Ruby core developers and Matz. Since then, we have successfully completed the port of YJIT to Rust. The new Rust version of YJIT has reached parity with the C version, in that it passes all the CRuby tests, is able to run all of the YJIT benchmarks, and performs similarly to the C version (because it works the same way and largely generates the same machine code). We've even incorporated some design improvements, such as a more fine-grained constant invalidation mechanism which we expect will make a big difference in Ruby on Rails applications. Because we want to be careful, YJIT is guarded behind a configure option: ```shell ./configure --enable-yjit # Build YJIT in release mode ./configure --enable-yjit=dev # Build YJIT in dev/debug mode ``` By default, YJIT does not get compiled and cargo/rustc is not required. If YJIT is built in dev mode, then `cargo` is used to fetch development dependencies, but when building in release, `cargo` is not required, only `rustc`. At the moment YJIT requires Rust 1.60.0 or newer. The YJIT command-line options remain mostly unchanged, and more details about the build process are documented in `doc/yjit/yjit.md`. The CI tests have been updated and do not take any more resources than before. The development history of the Rust port is available at the following commit for interested parties: https://github.com/Shopify/ruby/commit/1fd9573d8b4b65219f1c2407f30a0a60e537f8be Our hope is that Rust YJIT will be compiled and included as a part of system packages and compiled binaries of the Ruby 3.2 release. We do not anticipate any major problems as Rust is well supported on every platform which YJIT supports, but to make sure that this process works smoothly, we would like to reach out to those who take care of building systems packages before the 3.2 release is shipped and resolve any issues that may come up. [issue]: https://bugs.ruby-lang.org/issues/18481 Co-authored-by: Maxime Chevalier-Boisvert <[email protected]> Co-authored-by: Noah Gibbs <[email protected]> Co-authored-by: Kevin Newton <[email protected]> Notes: Merged: https://github.com/ruby/ruby/pull/5826