| 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 |
|||
|
00:47
jjatria left,
jjatria joined
05:16
jdv left,
jdv joined
05:43
SmokeMachine left,
SmokeMachine joined
08:28
Geth left,
Geth joined
09:40
nine left,
nine joined
10:05
ilogger2 left,
ilogger2 joined
10:40
ShimmerFairy left
12:16
ShimmerFairy joined
16:14
rba left
16:15
rba joined
|
|||
| 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 | |||
|
21:18
disbot2 joined,
disbot left
|
|||
| 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 | |
|
21:39
coverable6 left
|
|||
| 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 | ||