May 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113599] [Ruby master Bug#16265] Test (spec) failure using current MSYS2 tools, related to -fstack-protector and possibly D_FORTIFY_SOURCE=2
by ioquatix (Samuel Williams) 23 May '23

23 May '23

Issue #16265 has been updated by ioquatix (Samuel Williams). For some reason, this also started breaking on Windows in this PR and I had to disable it https://github.com/ruby/ruby/pull/7827/files I cannot see how anything in my PR would impact the test that was hanging. It seems like it might relate to the method length, so I might try reworking the PR to move the `pread`/`pwrite` functionality into a separate function completely. However, I don't see why it should matter at all. ---------------------------------------- Bug #16265: Test (spec) failure using current MSYS2 tools, related to -fstack-protector and possibly D_FORTIFY_SOURCE=2 https://bugs.ruby-lang.org/issues/16265#change-103240 * Author: MSP-Greg (Greg L) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.0dev (2019-10-19T08:19:27Z master 1d435bd51a) [x64-mingw32] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- GH PR https://github.com/ruby/ruby/pull/2573 was a work-around that forced using some non-current MSYS2 packages libraries for building. These libraries are only available on Appveyor because their images are out-of-date, a new MSYS2 install would not have them. Using current MSYS2 libraries requires adding '-fstack-protector' to LDFLAGS. I also experimented with adding 'D_FORTIFY_SOURCE=2' to CFLAGS. Ruby build/compiles with those flags added. test-all passes. But spec tests always lock up when running: ``` C-API Thread function rb_thread_call_without_gvl - runs a C function with the global lock unlocked - runs a C function with the global lock unlocked amd unlocks IO with the generic RUBY_UBF_IO ``` The tests are in spec/ruby/optional/capi/thread_spec.rb, as shown: https://github.com/ruby/ruby/blob/1d435bd51aeca75f6e437bc92de2271a716a1ced/… and the freeze occurs on line 137. I've run this once in ruby-loco, twice in my ruby fork, and several times locally. In all runs, test-all passed, and spec stopped at the test above. This uses gcc 9.2.0, and the problem would occur with anyone doing a 'fresh' install of MSYS2. Not being a c type, this is way beyond what I can fix. Happy to try patches, etc. Thanks, Greg -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113591] [Ruby master Feature#17325] Adds Fiber#cancel, which forces a Fiber to break/return
by ioquatix (Samuel Williams) 22 May '23

22 May '23

Issue #17325 has been updated by ioquatix (Samuel Williams). Status changed from Open to Closed We introduced `Fiber#kill` which behaves exactly as requested by the proposal. > Calling Fiber#cancel will force a fiber to return, skipping rescue and catch blocks but running all ensure blocks. It behaves as if a break or return were used to jump from the last suspension point to the top frame of the fiber. Control will be transferred to the canceled fiber so it can run its ensure blocks. ---------------------------------------- Feature #17325: Adds Fiber#cancel, which forces a Fiber to break/return https://bugs.ruby-lang.org/issues/17325#change-103230 * Author: nevans (Nicholas Evans) * Status: Closed * Priority: Normal ---------------------------------------- Calling `Fiber#cancel` will force a fiber to return, skipping rescue and catch blocks but running all ensure blocks. It behaves as if a `break` or `return` were used to jump from the last suspension point to the top frame of the fiber. Control will be transferred to the canceled fiber so it can run its ensure blocks. ## Propagation from resuming to resumed fibers Any non-root living fiber can be canceled and cancellation will propagate to child (resumed) fibers. In this way, a suspended task can be canceled even if it is e.g. resuming into an enumerator, and the enumerator will be canceled as well. Transfer of control should match #17221's *(much improved)* transfer/resume semantics. After the cancellation propagates all the way to the bottom of the fiber resume stack, the last fiber in the chain will then be resumed. Resuming fibers will not run until they are yielded back into. ## Suspension of canceled fibers Canceled fibers can still transfer control with `resume`, `yield`, and `transfer`, which may be necessary in order to release resources from `ensure` blocks. For simplicity, subsequent cancels will behave similarly to calling `break` or `return` inside an `ensure` block, and the last cancellation reason will overwrite earlier reasons. ## Alternatives `Fiber#raise` could be used, but: * Can only raise on resumable fibers. * Cannot propagate cancellation down to resumed fibers. * Exceptions are bigger and slower than `break`. * `#raise` can't (and shouldn't) be sent to resuming fibers. (It can't propagate.) * Exceptions can be caught. This might be desirable, but that should be at the discretion of the calling fiber. Catch/Throw could be used (with an anonymous `Object.new`), but: * We would need to add `Fiber#throw` (or wrap/intercept `Fiber.yield`). * A hypothetical `Fiber#throw` should probably have similar semantics to `#resume` and thus only be allowed on resumable fibers. * In that case, it wouldn't propagate down to resumed fibers. * `catch` adds an extra stack frame. We could use go-style "Context" objects that contain a "done?" queue/future. * These would need to be explicitly passed around. * Although their usage could be enforced via linters like rubocop, I think that placing it off to the side will give developers the impression that it is optional Some sort of cancel propagation mechanism is not optional for structured concurrency. * It should built into any task-scheduler library, which would allow application code to use it explicitly. * But this suffers the same problem as current Fiber wrappers: it works fine if your code uses the wrapper, but code that uses fibers without the wrapper can be incompatible and introduce bugs (e.g. fibers that are released without running their `ensure` blocks). * This make sense for a language like go which doesn't have exceptions but does have a convention of returning an "error" value. It feels out of place in ruby, IMO. Letting the fiber-task-scheduler mitigates that... for code that uses the fiber-task-scheduler. We could add a keyword option to `Fiber#raise` that gives it similar propagation semantics to this. * IMO, the simplicity of `Fiber#raise` simply being a specialized version of `Fiber#resume` is worth preserving. * The propagation changes alone are enough of a semantic difference to warrant a new method. We could implement `Fiber#cancel` by using `fiber.raise(FiberCancellationError)` on the bottom fiber and catching that exception during termination of the canceled fiber. * This would have the "benefit" that the exception could be rescued. * I might be wrong, but I think that doing this would mostly duplicate my PR, but with some added complexity around exception construction and catching. * It might be a good keyword option? e.g. `Fiber#cancel(with_exception: [true,#exception,#to_str])` Just let the task-fiber-scheduler library handle this. * That's what I'm already doing now. It's mostly fine. It works in my code. * Putting it into ruby core should lead to a small performance boost on very commonly repeated code. * There's probably a better way to store the `cancel_reason` that doesn't require the overhead of adding another `VALUE` to `rb_fiber_struct`. Maybe it can be placed directly into `errinfo`? * Although the common cases can be handled via a trampoline fiber or #17221, there can still be situations where your application's fiber-scheduler library might not know about fibers created by other libraries. This adds interoperability to a common scenario. * Coroutine cancellation is IMO a core feature. It's important to have something like this for all applications and libraries to use as a baseline for interoperability. Implementation: https://github.com/ruby/ruby/pull/3766 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113588] [Ruby master Bug#19084] Using `IO::Buffer` to change an extended String affects other Strings sharing the same buffer
by ioquatix (Samuel Williams) 21 May '23

21 May '23

Issue #19084 has been updated by ioquatix (Samuel Williams). Merged in https://github.com/ruby/ruby/commit/bd786e78969f9d4a8699376ceafe10934b6ad533. ---------------------------------------- Bug #19084: Using `IO::Buffer` to change an extended String affects other Strings sharing the same buffer https://bugs.ruby-lang.org/issues/19084#change-103223 * Author: jemmai (Jemma Issroff) * Status: Open * Priority: Normal * ruby -v: master * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- When two extended Strings share a buffer, and one String's buffer changes, it currently affects the other String's buffer. Here is a snippet to demonstrate this: ``` string = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" other_string = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" IO::Buffer.for(string) do |buffer| buffer.set_value(:U8, 0, "*".ord) end other_string[0] == "a" # => false ``` [Here is a PR which adds the above example as a test](https://github.com/ruby/ruby/pull/6630), and is currently failing CI. (cc @ioquatix) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113586] [Ruby master Bug#19084] Using `IO::Buffer` to change an extended String affects other Strings sharing the same buffer
by ioquatix (Samuel Williams) 21 May '23

21 May '23

Issue #19084 has been updated by ioquatix (Samuel Williams). This should be fixed by https://bugs.ruby-lang.org/issues/19084. ---------------------------------------- Bug #19084: Using `IO::Buffer` to change an extended String affects other Strings sharing the same buffer https://bugs.ruby-lang.org/issues/19084#change-103218 * Author: jemmai (Jemma Issroff) * Status: Open * Priority: Normal * ruby -v: master * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- When two extended Strings share a buffer, and one String's buffer changes, it currently affects the other String's buffer. Here is a snippet to demonstrate this: ``` string = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" other_string = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" IO::Buffer.for(string) do |buffer| buffer.set_value(:U8, 0, "*".ord) end other_string[0] == "a" # => false ``` [Here is a PR which adds the above example as a test](https://github.com/ruby/ruby/pull/6630), and is currently failing CI. (cc @ioquatix) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112072] [Ruby master Bug#19386] `test_hmac.rb` of openssl is timeout on RHEL9
by hsbt (Hiroshi SHIBATA) 21 May '23

21 May '23

Issue #19386 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19386: `test_hmac.rb` of openssl is timeout on RHEL9 https://bugs.ruby-lang.org/issues/19386 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I prepared new test instance of RHEL9 for https://rubyci.org/. But it stuck with openssl tests. see http://rubyci.s3.amazonaws.com/rhel9/ruby-master/log/20230127T003004Z.fail.… I did bisect this issue. This issue caused by https://github.com/ruby/ruby/blob/master/test/openssl/test_hmac.rb#L23 ``` def test_dup h1 = OpenSSL::HMAC.new("KEY", "MD5") h1.update("DATA") h = h1.dup assert_equal(h1.digest, h.digest, "dup digest") end ``` Stuck is happened after running this test. /cc @vo.x @jaruga @rhenium -- https://bugs.ruby-lang.org/

7 13

[ruby-core:113045] [Ruby master Feature#19559] Introduce `Symbol#+@` and `Symbol#-@`, and eventually replace boolean arguments with symbols
by sawa (Tsuyoshi Sawada) 21 May '23

21 May '23

Issue #19559 has been reported by sawa (Tsuyoshi Sawada). ---------------------------------------- Feature #19559: Introduce `Symbol#+@` and `Symbol#-@`, and eventually replace boolean arguments with symbols https://bugs.ruby-lang.org/issues/19559 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- I propose to define `Symbol#+@` and `Symbol#-@`, so that we can add positive or negative polarity to symbols. A possible implementation can be equivalent to what can be achieved by this: ```ruby class Symbol def -@; "-#{self}".to_sym end def +@; self end end ``` The intention behind this is to, eventually, replace boolean positional or keyword arguments with symbols so that, instead of this: ```ruby "foo".methods(false) gets(chomp: true) Integer("2.3", exception: false) ``` we can write like this: ```ruby "foo".methods(-:inherit) gets(+:chomp) Integer("2.3", -:exception) ``` -- https://bugs.ruby-lang.org/

8 19

[ruby-core:113435] [Ruby master Feature#19634] Pattern matching dynamic key
by baweaver (Brandon Weaver) 19 May '23

19 May '23

Issue #19634 has been reported by baweaver (Brandon Weaver). ---------------------------------------- Feature #19634: Pattern matching dynamic key https://bugs.ruby-lang.org/issues/19634 * Author: baweaver (Brandon Weaver) * Status: Open * Priority: Normal ---------------------------------------- I found myself in a situation ([stable marriage problem](https://rosettacode.org/wiki/Stable_marriage_problem#top-page)) where I would like to match against a dynamic key, like so: ```ruby mentor_proposals = { mentor_name: ['mentee_1', 'mentee_2'] } mentor_name = :mentor_name mentee_name = 'mentee_1' mentor_proposals in ^key: [*, ^mentee_name, *] # SyntaxError ``` Currently this is not supported syntax, but there are some use cases in which I might see myself wanting to use it including this one. As `deconstruct_keys` currently accepts an `Array` of keys this would not break compatibility but would introduce syntactic complexity in capturing keys on hash-like matches. I believe the tradeoff is worthwhile, but would like to hear others opinions on the matter. Granted this case has some oddities of `Symbol` and `String` interchangeability as an implementation detail, and I will not be arguing for key irreverence in this issue as that's a [much more involved topic](https://dev.to/baweaver/the-case-for-pattern-matching-key-irreverence-in-ruby-1oll). -- https://bugs.ruby-lang.org/

5 5

[ruby-core:113531] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by marcper (Marcelo Pereira) 19 May '23

19 May '23

Issue #18743 has been updated by marcper (Marcelo Pereira). The exceptions are already being chained through `cause`, but I've just updated the tests to make this fact clearer. Indeed a new exception is created every time. Initially I looked for an API to simply update the backtrace on the existing exception, and couldn't find one. But given the need to chain exceptions, creating a new one every time turned out to be the right approach. Thank you for reviewing this, @nobu, and I'm happy to address any other concerns. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-103158 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113303] [Ruby master Feature#19610] GC.delay_promotion
by peterzhu2118 (Peter Zhu) 19 May '23

19 May '23

Issue #19610 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #19610: GC.delay_promotion https://bugs.ruby-lang.org/issues/19610 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- GitHub Pull Request: https://github.com/ruby/ruby/pull/7683 I'm proposing `GC.delay_promotion`, which is a feature that changes characteristics of the garbage collector. When set to `false` (the default value), the GC keeps the original behavior. This means that references from an old object to a write barrier protected young object will immediately promote the young object. References from an old object to a write barrier unprotected object will place the write barrier unprotected object in the remember set for marking during minor collections. When set to `true`, references from an old object to a write barrier protected young object will not immediately promote the young object. Instead, the young object will age just like any other object, meaning that it has to survive three collections before being promoted to the old generation. References from an old object to a write barrier unprotected object will place the parent object in the remember set for marking during minor collections. This allows the child object to be reclaimed in minor collections at the cost of increased time for minor collections. On one of [Shopify's highest traffic Ruby apps, Storefront Renderer](https://shopify.engineering/how-shopify-reduced-storefront-response-times-rewrite), we saw significant improvements after deploying this feature in production. In the graphs below, we compare the GC time and response time of web workers that have `GC.delay_promotion = false` (non-experimental group) and `GC.delay_promotion = true` (experimental group). We see that with this feature we spend significantly less time in the GC, 0.81x on average, 0.88x on p99, and 0.45x on p99.9. ![](Screenshot%202023-04-20%20at%2011.50.26%20AM.png) This translates to improvements in average response time (0.96x) and p99 response time (0.92x). ![](Screenshot%202023-04-20%20at%2011.50.38%20AM.png) In benchmarks, this feature performs better in some scenarios and worse in others. However, these benchmarks are usually not a good indicator as there are few old objects and major collections are not a significant bottleneck. ``` -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- bench master (ms) stddev (%) RSS (MiB) branch (ms) stddev (%) RSS (MiB) branch 1st itr master/branch activerecord 70.7 0.2 54.4 70.5 0.3 54.7 1.01 1.00 erubi_rails 20.5 2.0 103.0 20.7 2.2 102.2 0.94 0.99 hexapdf 2470.1 0.3 275.6 2475.4 0.7 215.9 1.03 1.00 liquid-c 65.2 1.4 39.8 65.4 0.3 39.7 1.05 1.00 liquid-compile 59.5 3.4 38.9 57.5 3.0 38.3 0.99 1.04 liquid-render 164.3 1.1 36.1 159.8 0.2 35.5 1.02 1.03 mail 135.7 0.2 50.2 135.3 0.1 50.0 1.00 1.00 psych-load 2053.0 0.0 36.4 2003.3 0.1 35.3 1.03 1.02 railsbench 2001.8 0.7 107.1 1965.1 0.0 107.3 1.00 1.02 ruby-lsp 67.1 8.7 94.6 65.1 0.8 92.8 0.97 1.03 sequel 72.4 0.2 40.4 71.3 0.2 40.4 1.01 1.02 -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- ``` ---Files-------------------------------- Screenshot 2023-04-20 at 11.50.26 AM.png (527 KB) Screenshot 2023-04-20 at 11.50.38 AM.png (350 KB) -- https://bugs.ruby-lang.org/

3 8

[ruby-core:113513] [Ruby master Feature#19678] Don't immediately promote children of old objects
by peterzhu2118 (Peter Zhu) 18 May '23

18 May '23

Issue #19678 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #19678: Don't immediately promote children of old objects https://bugs.ruby-lang.org/issues/19678 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- This is an alternate proposal to #19610 where the feature is not configurable and always enabled. GitHub Pull Request: https://github.com/ruby/ruby/pull/7821 References from an old object to a write barrier protected young object will not immediately promote the young object. Instead, the young object will age just like any other object, meaning that it has to survive three collections before being promoted to the old generation. References from an old object to a write barrier unprotected object will place the parent object in the remember set for marking during minor collections. This allows the child object to be reclaimed in minor collections at the cost of increased time for minor collections. On one of [Shopify's highest traffic Ruby apps, Storefront Renderer](https://shopify.engineering/how-shopify-reduced-storefront-response-times-rewrite), we saw significant improvements after deploying this feature in production. In the graphs below, we compare the GC time and response time of web workers that have `GC.delay_promotion = false` (non-experimental group) and `GC.delay_promotion = true` (experimental group). We see that with this feature we spend significantly less time in the GC, 0.81x on average, 0.88x on p99, and 0.45x on p99.9. ![](Screenshot%202023-04-20%20at%2011.50.26%20AM.png) This translates to improvements in average response time (0.96x) and p99 response time (0.92x). ![](Screenshot%202023-04-20%20at%2011.50.38%20AM.png) In benchmarks, this feature performs better in some scenarios and worse in others. However, these benchmarks are usually not a good indicator as there are few old objects and major collections are not a significant bottleneck. ``` -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- bench master (ms) stddev (%) RSS (MiB) branch (ms) stddev (%) RSS (MiB) branch 1st itr master/branch activerecord 70.7 0.2 54.4 70.5 0.3 54.7 1.01 1.00 erubi_rails 20.5 2.0 103.0 20.7 2.2 102.2 0.94 0.99 hexapdf 2470.1 0.3 275.6 2475.4 0.7 215.9 1.03 1.00 liquid-c 65.2 1.4 39.8 65.4 0.3 39.7 1.05 1.00 liquid-compile 59.5 3.4 38.9 57.5 3.0 38.3 0.99 1.04 liquid-render 164.3 1.1 36.1 159.8 0.2 35.5 1.02 1.03 mail 135.7 0.2 50.2 135.3 0.1 50.0 1.00 1.00 psych-load 2053.0 0.0 36.4 2003.3 0.1 35.3 1.03 1.02 railsbench 2001.8 0.7 107.1 1965.1 0.0 107.3 1.00 1.02 ruby-lsp 67.1 8.7 94.6 65.1 0.8 92.8 0.97 1.03 sequel 72.4 0.2 40.4 71.3 0.2 40.4 1.01 1.02 -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- ``` ---Files-------------------------------- Screenshot 2023-04-20 at 11.50.26 AM.png (527 KB) Screenshot 2023-04-20 at 11.50.38 AM.png (350 KB) -- https://bugs.ruby-lang.org/

1 0