| 7 Aug 2026 | |||
| [Coke] | Finished with result: oom-kill | 12:31 | |
| so, didn't finish with a bisect, but see two failures: | |||
| output_Mux_0.0.4 output_Text::Markdown::Discount_0.3.0 | |||
| I'll redo it with the original # of cores I happened to use. | |||
| timo: wonder if it would make sense to do *each test* in blin in the systemd container, rather than the whole thing. | 12:37 | ||
| tellable6 | [Coke], I'll pass your message to timo | ||
| [Coke] | Would be nice for blin to be able to say what it was working on when killed by OOM. | 12:44 | |
| wonder if I should do a run with a single core, and set the memory limit to something lower than the max so I can see which module is the one spiking the memory (and then potentially skip that or do it separately) | 12:46 | ||
| Geth | rakudo/main: 669ad276d5 | (Dan Kogai)++ (committed using GitHub Web editor) | 3 files Add %a/%A (C99 hex float) directives to the 6.e Formatter As suggested by lizmat in the review of the nqp counterpart (Raku/nqp#859): make the hexadecimal floating point directives also available in the RakuAST-based Formatter used by 6.e, so that %a keeps working when Formatter becomes the sprintf engine. ... (16 more lines) |
13:46 | |
| linkable6 | NQP#859 [closed]: github.com/Raku/nqp/pull/859 Add %a/%A (C99 hex float) directives to HLL sprintf | ||
| [Coke] | oh, I thought that was already merged. | 13:48 | |
| c: 669ad276d5 pi.say | |||
| committable6 | [Coke], ¦669ad27: «Cannot find this revision (did you mean “637ba57”?)» | ||
| lizmat | [Coke]: I was waiting for CI to turn green, it had a flapper turns out later | 13:50 | |
| also: am working on some optimizations now in Formatter | |||
| [Coke] | ah | 13:52 | |
| cool. | |||
| potential issue in output_Concurrent::Stack_1.3 on this run | 14:09 | ||
| interesting. got another OOM kill, this time it was over 93.95% done, after 1h35min | 14:11 | ||
| oddly it says memory peak was 28.8G (6.2G swap) - but I had the killer set for 30G | 14:12 | ||
| c: 669ad276d5 pi.say | 14:14 | ||
| committable6 | [Coke], ¦669ad27: «3.141592653589793» | ||
| [Coke] | ok, running *again* but this time doing a ps check to see if I can figure out where the memory is going near the end there. | 14:15 | |
| surely there is a better tool than me running 'ps | grep perl6' in a loop and then post-processing that file. :) | 14:16 | ||
| The fact that I can do nearly a complete run in 90m here is insane, though. :| | 14:17 | ||
| ugexe | Concurrent::Stack comes up occasionally. it is a flapper | 14:23 | |
| lizmat | indeed... I just had a flapper after increasing the number of threads to 30 | 14:27 | |
| No exception handler located for catch | |||
| originating apparently at: SETTING::src/core.c/atomicops.rakumod:154 | |||
| ugexe | "The actual cause is a MoarVM race. A containerized $ attribute with no default leaves its P6opaque slot NULL until first access. Auto-viv cloned a fresh Scalar container per racing thread and installed it with a plain slot write. Threads racing the first cas $!head, {...} each mutated their own container, and the losing install was silently discarded, so the stack lost the losing thread's first | ||
| push and a later pop legitimately hit empty." | |||
| i didn't spend too much time looking into this solution since it isn't welcome in moarvm in the first place but in my testing (on a non-x86 arch, so the JIT changes in particular are theoretical) github.com/ugexe/MoarVM/commit/5f1...e242767349 resolves the issue. maybe someone else can fix it in moarvm though | 14:57 | ||
| [Coke] | ah. I had a smallish swap on this new box. Cranked that up, should be better. | 15:11 | |
| ab5tract | ugexe: to resurrect the int/ Int dispatcher— maybe it’s worth asking what the use case of such a multi would be? The whole subject resonates on a DIHWIDT frequency for me, but probably I’m probably just missing the utility of the thing | 15:21 | |
| ugexe | the use case is mostly CORE itself. +, div, *, etc all have (int,int) and (Int,Int) candidates so native-typed code stays on machine ops instead of boxing every operation. you hit the dispatch question every time you write my int $i; $i div 0 whether or not you ever wrote such a multi yourself, because 0 is the literal and CORE has both candidates | 15:30 | |
| and the problem i was chasing wasn't really which candidate is ideal, it's that the answer changed with the optimizer. f(0) went native at default optimization if the candidate happened to be inlinable, and boxed otherwise. so my int $i = 4; my $r = $i div 0 throws by default and soft-fails at --optimize=off | 15:31 | ||
| lizmat | I just found another case of unexpected boxing | 15:34 | |
| m: use nqp; my int $a = 42; dd nqp::concat("foo",$a) | |||
| camelia | "foo42" | ||
| lizmat | an int coerces silently to str | ||
| m: use nqp; my int $a = 42; dd nqp::concat("foo",$a < 100 ?? $a !! "100") # but not inside a ternary | |||
| camelia | This container does not reference a native string in block <unit> at <tmp> line 1 |
||
| ugexe | the rule i landed on is basically dispatch follows the representation that is actually passed. the refinement is what a literal's representation is, since it has no declared type. beside exactly one native operand it takes that native form, anywhere else it is the Int it literally is. so f(0) goes to f(Int $), and $i + 1 still hits add_i. forcing the literal boxed there costs like 18x in a hot | 15:36 | |
| loop when i measured it. i tried the literal just IS an int path, but it breaks anything that introspects captures because natives start flowing into code that expects objects | |||