Newest at the top
| 2026-06-08 10:31:11 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-08 10:28:14 +0000 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) (Ping timeout: 256 seconds) |
| 2026-06-08 10:28:13 +0000 | <Freakie> | if you already have programming experience it's never a bad idea to learn something new |
| 2026-06-08 10:27:29 +0000 | <vivaldi`> | could be fun to learn :) |
| 2026-06-08 10:26:10 +0000 | <Freakie> | depends on your needs/interests I think |
| 2026-06-08 10:25:01 +0000 | <vivaldi`> | I don't do haskell. should I try it? |
| 2026-06-08 10:24:37 +0000 | <vivaldi`> | hello haskellians! |
| 2026-06-08 10:24:09 +0000 | <Freakie> | most of my live data is gated behind compacts which are treated as write-only data so that explains a lot honestly |
| 2026-06-08 10:23:55 +0000 | vivaldi` | (~ident@user/blackbox) blackbox |
| 2026-06-08 10:23:27 +0000 | <Freakie> | only downside to this is that it's completely tangential to my hypothesis but oh well |
| 2026-06-08 10:21:59 +0000 | misterfish | (~misterfis@178.230.99.247) misterfish |
| 2026-06-08 10:21:27 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 248 seconds) |
| 2026-06-08 10:18:58 +0000 | <tomsmeding> | the extent to which this effect exists, depends on the distribution of lifetimes of your live data |
| 2026-06-08 10:18:09 +0000 | <tomsmeding> | Freakie: right, assuming most data has a finite lifetime, larger nursery means less data gets promoted to gen 0 at each minor GC, so gen 0 grows more slowly, so gen 0 overflow triggers major GC less often |
| 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. |