| 6 Aug 2026 | |||
| [Coke] | our guy will be submitting one for the other BSDs and we need a small portability work to get it going on those. | 13:36 | |
| timo | easier to just use a docker image of a debian system than to run a full vm I assume (haven't looked at the code, only the description) | 13:40 | |
| though we could use a VM setup to test debian/kFreeBSD ;) | |||
| 7 Aug 2026 | |||
| Geth | MoarVM/moar-rrdb-2: 18 commits pushed by (Timo Paulssen)++ review: github.com/MoarVM/MoarVM/compare/d...796a57bb0e |
19:48 | |
| 10 Aug 2026 | |||
| lizmat | And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2026/08/10/2026-...ating-hex/ | 15:22 | |
| 13 Aug 2026 | |||
| [Coke] | FYI, I'm pulling in one of ugexe's branches into MoarVM so I can test it with blin and our CI. | 18:27 | |
| Geth | MoarVM/ugexe/demand-object-pending-repossession: cb4feec9d6 | (Nick Logan)++ | 3 files Install pending object repossession target in demand_object MVM_serialization_deserialize queues every repossessed STable for body deserialization and then runs the object repossession loop. Inside that loop, resolving a row's updated STable through read_object_table_entry can demand one of the compilation unit's own STables, which enters the work loop and deserializes the queued STable bodies. Deserializing an ... (52 more lines) |
18:29 | |
| 18 Aug 2026 | |||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2026/08/18/2026-...-infinity/ | 14:25 | |
| 22 Aug 2026 | |||
| Geth | MoarVM/2026.08: 801b77f2a8 | (Will Coleda)++ | 2 files Update changelog and version |
00:19 | |
| MoarVM: coke++ created pull request #2034: Update changelog and version |
00:30 | ||
| MoarVM/main: 801b77f2a8 | (Will Coleda)++ | 2 files Update changelog and version |
|||
| MoarVM/main: c3cc02d8d6 | (Will Coleda)++ (committed using GitHub Web editor) | 2 files Merge pull request #2034 from MoarVM/2026.08 Update changelog and version |
|||
| timo | by introducing a new syscall like `forget-frame-data` or whatever, and using it on the `<unit>` frame, especially on the core setting, we can save a bit of memory at run time; the core.c setting's `<unit>` frame has a 50 kbyte big "work_initial" (data to initialise the registers with when calling the frame) and an inline cache of 113 kbytes, plus maybe two hundred or three entries in the inline | 21:00 | |
| cache of which at least some have a dispatch program in them which are not huge but also not nothing | |||
| lizmat | apart from the memory savings, would there be an improvement in execution speed as well ? | 21:28 | |
| timo | no | 21:30 | |
| the unit frame of the core setting is a frame that is run just a single time and never again, at least if nobody is doing silly things | 21:31 | ||
| that's why I claim it's fine to throw that data that i mentioned away | 21:32 | ||
| lizmat | would it help in startup ? | ||
| timo | the only effect it would have on startup time would be that we free a bunch of allocations which means other allocs can take their place? so mimalloc will not have to pull in more memory from the system for just a little longer | 21:33 | |
| the largest of these allocations are kind of inert, they would at some point just be paged out and not be paged back in | 21:34 | ||
| the smaller allocations would share their pages with other allocations which may not be as rarely accessed, so they could be wasting tiny amounts of memory traffic in those cases? | 21:35 | ||
| lizmat | why would we need a syscall for it? why don't we let it at the end of the frame do it itself ? | ||
| or is that your point: create a syscall, and call this at the end of the frame ? | 21:36 | ||
| timo | this can only be done in frames that won't get called a second time, which we usually don't know ahead of time | ||
| yes | |||
| we'd just generate it as the last operation before the return in the <unit> frame when compiling the core setting | 21:37 | ||
| lizmat | would that also apply to the base EVAL frames ? | ||
| timo | not sure, but may be easy to find out? | 21:38 | |
| lizmat | too hard for me, too tired :-) sleep& | 21:41 | |
| timo | gnite! | ||
| well, those measurements make literally no sense? | 21:59 | ||
| the discrepancy i was seeing came from the fact that the stuff in the inline cache were put into the "free at safepoint" list at one 16 byte allocation per entry that needed throwing away, so instead of immediately freeing a bunch of memory for re-use, it was allocating a bunch more memory and the freeing would only happen when hitting the next GC run | 23:34 | ||
| 23 Aug 2026 | |||
| [Coke] | m: say 86*.4 | 01:17 | |
| camelia | 34.4 | ||
| timo | what's that for? | ||
| [Coke] | ww | 01:25 | |