| 3 Jan 2026 | |||
| timo | > Last Build Status: In-queue. Your build is in the queue to be analyzed. There are 2 builds ahead of it. | 15:27 | |
| > Sep 07, 2022 Last Analyzed | 15:28 | ||
| scan.coverity.com/projects/paultcochrane-moarvm - i'm not sure if just anybody can open the defects viewer or if you need to log in to this site with an account first | 15:34 | ||
| Geth | MoarVM/event_loop_started_status_without_mutex: f4e5a0a78f | (Timo Paulssen)++ | 6 files Use atomic instead of mutex for "is event loop started" The theory is that reading an atomic that only very rarely changes is cheaper than locking and unlocking a mutex for reading. Coverity Scan pointed out in CID 501093 that another thread could see instance->event_loop_thread become nonzero before the other field writes would be complete, thus causing a data race. ... (6 more lines) |
17:18 | |
| MoarVM/event_loop_started_status_without_mutex: f8c251c6d3 | (Timo Paulssen)++ | 6 files Use atomic instead of mutex for "is event loop started" The theory is that reading an atomic that only very rarely changes is cheaper than locking and unlocking a mutex for reading. Coverity Scan pointed out in CID 501093 that another thread could see instance->event_loop_thread become nonzero before the other field writes ... (11 more lines) |
17:19 | ||
| MoarVM/event_loop_started_status_without_mutex: 30c938d96c | (Timo Paulssen)++ | 4 files telemeh: make forks visible, continue working after fork |
19:20 | ||
| MoarVM/timo_january_2026_coverityscan: 5 commits pushed by (Timo Paulssen)++ | 19:21 | ||
| 4 Jan 2026 | |||
| MoarVM/perf_jitdump_support: 5 commits pushed by (Timo Paulssen)++ | 02:13 | ||
| 5 Jan 2026 | |||
| librasteve_ | rakudoweekly.blog/2026/01/05/2026-...happy-new/ | 15:28 | |
| 7 Jan 2026 | |||
| Geth | MoarVM/region_allocator_always_align_eight: 2d27f825f1 | (Timo Paulssen)++ | src/core/regionalloc.c Always align region allocator allocations to multiples of 8 GCC 15.1 on OpenSuse Leap 16 mysteriously started using SIMD to optimize functions working with the succ, pred, or child arrays of BBs in spesh, causing a segfault when the allocation behaviour of the program caused one of these arrays to land on an address divisible by 4 but not by 8. Hopefully it's not a huge penalty to always align to 8 here. Shout-out to denizens of the Compiler Explorer Discord server for helping me diagnose what the compiler was up to. |
17:19 | |
| MoarVM: timo++ created pull request #1984: Always align region allocator allocations to multiples of 8 |
|||