Newest at the top
| 2026-06-08 10:05:05 +0000 | Axma40140 | (~Axman6@user/axman6) (Ping timeout: 245 seconds) |
| 2026-06-08 09:58:53 +0000 | <Freakie> | at any rate I did finally find a paper describing the GC triggers in detail, so I guess there is that |
| 2026-06-08 09:53:30 +0000 | <Freakie> | less space on average* |
| 2026-06-08 09:53:17 +0000 | <Freakie> | just because more gets cleaned up by the time it's pushed to gen 0, the older generations will take up less space on the heap and therefore require fewer allocations from the OS? (which would trigger major gc) |
| 2026-06-08 09:50:59 +0000 | <Freakie> | oh you mean |
| 2026-06-08 09:50:23 +0000 | <merijn> | Growing the nursery makes it last longer until it's full, which means there's more time for nursery data to die before graduating |
| 2026-06-08 09:49:33 +0000 | <merijn> | Freakie: Right, but if the entire nursery is dead by the time you GC, then nothing graduates to gen 0 |
| 2026-06-08 09:49:04 +0000 | <merijn> | It makes no sense to only work on the oldest generation |
| 2026-06-08 09:48:56 +0000 | <merijn> | major GC works on everything afaik? |
| 2026-06-08 09:43:46 +0000 | <Freakie> | at any rate evicting the nursery shouldn't require a major GC because it gets pushed to gen 0, while major GC only works on the oldest generation (as far as I've been able to infer) |
| 2026-06-08 09:43:10 +0000 | <Freakie> | nurseries are only garbage collected once full, right? remove the dead data and push the rest to gen 0 |
| 2026-06-08 09:36:33 +0000 | <merijn> | At least for some workflows |
| 2026-06-08 09:36:18 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) (Ping timeout: 246 seconds) |
| 2026-06-08 09:36:16 +0000 | <merijn> | So in that sense it seems very obvious that bigger nursery correlates with fewer major GC |
| 2026-06-08 09:35:55 +0000 | <merijn> | If bigger nursery causes it to stay in the nursery longer and die there **before** leaving the nursery, then you never need a major GC to get rid of it |
| 2026-06-08 09:35:46 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) |
| 2026-06-08 09:35:29 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) (Quit: Client closed) |
| 2026-06-08 09:35:25 +0000 | <merijn> | Because then it graduates out of the nursery and immediately dies, requiring a major GC to get rid off it |
| 2026-06-08 09:34:49 +0000 | acidjnk | (~acidjnk@p200300d6e700e514a755b21df9febc31.dip0.t-ipconnect.de) acidjnk |
| 2026-06-08 09:34:43 +0000 | <merijn> | Freakie: if the lifetime of your data was *slightly* longer than the time it stayed in the nursery. i.e. it dies very soon AFTER leaving the nursery that's, like, worst case scenario |
| 2026-06-08 09:33:38 +0000 | chele | (~chele@user/chele) chele |
| 2026-06-08 09:32:49 +0000 | <merijn> | If data never leaves the nursery than a major GC won't ever be needed |
| 2026-06-08 09:32:31 +0000 | <merijn> | One obvious reasons for "bigger nursery == less major GC" is that bigger nurseries don't fill up as fast, so stuff isn't aging out of it so fast |
| 2026-06-08 09:32:09 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 261 seconds) |
| 2026-06-08 09:31:56 +0000 | <merijn> | nurseries only trigger minor GC (i.e. only on the nursery, I think?) |
| 2026-06-08 09:30:13 +0000 | <tomsmeding> | there's one when threads seem to be deadlocked, for example (scheduleDetectDeadlock()) |
| 2026-06-08 09:30:00 +0000 | <tomsmeding> | Freakie: the entry points to GC seem to mostly be in rts/Schedule.c, in calls to scheduleDoGC() |
| 2026-06-08 09:28:17 +0000 | <Freakie> | but my point is that the exact triggers for major GC seems quite opaque to me beyond doing it when the program needs to move the heap anyway (i.e. allocate more from the OS) |
| 2026-06-08 09:24:19 +0000 | <Freakie> | it should only be minor |
| 2026-06-08 09:24:11 +0000 | <Freakie> | isn't that only minor gc? |
| 2026-06-08 09:24:08 +0000 | <tomsmeding> | I'm not sure whether it's minor or major, but GC definitely runs |
| 2026-06-08 09:24:01 +0000 | <tomsmeding> | GC runs when the nursery is exhausted |
| 2026-06-08 09:23:45 +0000 | <Freakie> | because that shouldn't have any effect on the allocation throughput |
| 2026-06-08 09:23:32 +0000 | <Freakie> | what I'm trying to say is that I don't know why having larger nurseries correlates to *performing* less major GC |
| 2026-06-08 09:23:12 +0000 | <tomsmeding> | the flip side is that spending more memory means less memory locality hence worse cache behaviour, potentially, though that depends very much on the sizes of everything involved |
| 2026-06-08 09:22:44 +0000 | <tomsmeding> | GC is O(live data); if you consistently allocate stuff but have a constant-size live data set, then a GC pass will consist of "iterate over your live data and forget all else". Then doing GC fewer times will use more peak memory but spend less time. |
| 2026-06-08 09:21:47 +0000 | <Freakie> | yes but that's not what's making the difference in my prgoram |
| 2026-06-08 09:21:29 +0000 | <tomsmeding> | well, GC takes time |
| 2026-06-08 09:21:16 +0000 | <Freakie> | which is the part I'm trying to understand why |
| 2026-06-08 09:21:11 +0000 | <Freakie> | the expectation is (and holds) that higher nursery size gives better performance with what I'm doing but it turns out to only be because higher nursery size correlates with fewer major garbage collections |
| 2026-06-08 09:20:47 +0000 | <Freakie> | anyway I'm running an experiment on an implementation where I use 4 MiB for the nursery size, and 32 MiB |
| 2026-06-08 09:20:08 +0000 | <tomsmeding> | right |
| 2026-06-08 09:20:08 +0000 | <Freakie> | as far as I understand it was one of the things that triggered major GC |
| 2026-06-08 09:19:59 +0000 | <Freakie> | that's what I mean by overflow |
| 2026-06-08 09:19:46 +0000 | <Freakie> | the runtime still needs to request memory from the OS whenever it runs out of addressable space |
| 2026-06-08 09:18:38 +0000 | <tomsmeding> | ok the user guide also speaks of "heap overflow" https://downloads.haskell.org/ghc/latest/docs/users_guide/hints.html#understanding-how-os-memory-u… |
| 2026-06-08 09:16:07 +0000 | bandola | (~bandola@c-5eea53c4-74736162.cust.telenor.se) |
| 2026-06-08 09:15:42 +0000 | bandola | (~bandola@user/bandola) (Ping timeout: 256 seconds) |
| 2026-06-08 09:13:11 +0000 | <tomsmeding> | (What is the underlying reason why you want to know about this?) |
| 2026-06-08 09:12:31 +0000 | <tomsmeding> | more than what? |