alanwu (Alan Wu)
- Login: alanwu
- Registered on: 10/28/2018
- Last sign in: 10/19/2026
Issues
| open | closed | Total | |
|---|---|---|---|
| Assigned issues | 2 | 33 | 35 |
| Reported issues | 1 | 51 | 52 |
Projects
| Project | Roles | Registered on |
|---|---|---|
| Ruby | Committer | 03/19/2021 |
Activity
Today
-
06:29 PM Ruby Bug #22396: Using rb_postponed_job_trigger causes YJIT/ZJIT compiled methods side exits
- > To be clear, both stackprof and the datadog profiler avoid this because they still sample the stack inside the signal handler -- the postponed jobs mechanism handles only the recording of the stack (which might e.g. involve expanding m...
10/18/2026
-
03:07 PM Ruby Bug #22414 (Closed): YJIT: arm64 panic "should not fail when writing to a fresh code page" when the code region fills at a page boundary — please backport 5a7089fc03fb to 3.4
- (closing because the branch maintainer looks at closed tickets for backports)
-
03:02 PM Ruby Bug #22396 (Closed): Using rb_postponed_job_trigger causes YJIT/ZJIT compiled methods side exits
- Postponed jobs are overall not great for sample collection because it's biased: C methods can run arbitrarily long without checking interrupts which then frames whatever ruby method afterwards with many samples. We've seen this happen wi...
10/14/2026
-
08:33 PM Ruby Revision e055c053 (git): ZJIT: Fix snapshot merge race
10/02/2026
-
10:59 AM Ruby Feature #22392: Allow refinements to define && and ||
- BTW, the cost analysis to non-users is incomplete in the PoC. Quantifying JIT time cost in terms of extra instructions doesn't talk about the optimizations otherwise possible that this inhibits.
The space analysis doesn't talk about all ...
09/30/2026
-
04:54 PM Ruby Feature #22392: Allow refinements to define && and ||
- Please no. Changing non-method call operations to be method calls has disastrous time and space cost for everyone involved, JIT or not. If accepted, this would be yet another case of refinement making people that do not use it pay in ter...
-
12:05 AM Ruby Revision 95543897 (git): ZJIT: Don't panic when calling RubyVM::ZJIT.reset_stats! with ZJIT off
- [Backport #22327] (The rust harness isn't setup for running code without
ZJIT, so the test is in ruby.)
09/29/2026
-
11:41 PM Ruby Bug #22327 (Closed): RubyVM::ZJIT.reset_stats! aborts the process (Rust panic) when ZJIT is not enabled
- Applied in changeset commit:git|b4eb7f249bf9dea7be48abd47a9ad0feac2bfa58.
----------
ZJIT: Don't panic when calling RubyVM::ZJIT.reset_stats! with ZJIT off
[Bug #22327] (The rust harness isn't setup for running code without
ZJIT, so th... -
11:41 PM Ruby Revision b4eb7f24 (git): ZJIT: Don't panic when calling RubyVM::ZJIT.reset_stats! with ZJIT off
- [Bug #22327] (The rust harness isn't setup for running code without
ZJIT, so the test is in ruby.) -
11:41 PM Ruby Revision 7e844b9e (git): ZJIT: Take VM lock in `RubyVM::ZJIT.reset_stats!` to avoid data race
- Data race happens when multi-ractor. Even before this patch, no one
seems to do (re)allocations without lock, so the I couldn't come up with
a case where the race ends in a crash. Let's not race (it's rust UB).