| 2026-06-08 00:04:29 +0000 | acidjnk | (~acidjnk@p200300d6e700e50741512d8f957d2df5.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-06-08 00:05:56 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 00:10:16 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 245 seconds) |
| 2026-06-08 00:10:17 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-08 00:21:20 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 00:26:00 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-08 00:27:39 +0000 | _\_ | (~o@user/offon) (Quit: ___) |
| 2026-06-08 00:28:06 +0000 | _\_ | (~o@user/offon) offon |
| 2026-06-08 00:37:08 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 00:37:58 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2026-06-08 00:41:51 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-08 00:52:53 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 00:57:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-06-08 01:10:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 01:15:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 253 seconds) |
| 2026-06-08 01:26:22 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 01:29:40 +0000 | fgarcia | (~lei@user/fgarcia) (Ping timeout: 252 seconds) |
| 2026-06-08 01:33:07 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-08 01:35:32 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-06-08 01:36:07 +0000 | rainbyte | (~rainbyte@181.47.219.31) (Read error: Connection reset by peer) |
| 2026-06-08 01:37:09 +0000 | rainbyte | (~rainbyte@181.47.219.31) rainbyte |
| 2026-06-08 01:40:02 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 248 seconds) |
| 2026-06-08 01:44:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 01:49:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 267 seconds) |
| 2026-06-08 01:50:10 +0000 | fgarcia | (~lei@user/fgarcia) fgarcia |
| 2026-06-08 01:59:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 02:04:45 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-08 02:09:30 +0000 | td_ | (~td@i5387090E.versanet.de) (Ping timeout: 241 seconds) |
| 2026-06-08 02:11:42 +0000 | td_ | (~td@i53870937.versanet.de) |
| 2026-06-08 02:15:47 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 02:16:44 +0000 | karenw | (~karenw@user/karenw) (Quit: Deep into that darkness peering...) |
| 2026-06-08 02:19:01 +0000 | rekahsoft | (~rekahsoft@70.51.99.119) rekahsoft |
| 2026-06-08 02:21:00 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 259 seconds) |
| 2026-06-08 02:31:35 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 02:35:48 +0000 | wickedjargon | (~user@2605:8d80:8100:486:a645:88dd:2cda:7f4) wickedjargon |
| 2026-06-08 02:36:39 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-06-08 02:47:21 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 02:52:10 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-06-08 02:52:46 +0000 | ricardomaps | (~ricardoma@2804:14d:a040:81ea:3035:8c54:ee2a:4632) (Quit: ricardomaps) |
| 2026-06-08 03:02:17 +0000 | rekahsoft | (~rekahsoft@70.51.99.119) (Remote host closed the connection) |
| 2026-06-08 03:03:10 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 03:10:10 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-08 03:10:57 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 03:15:30 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-08 03:23:30 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) (Ping timeout: 248 seconds) |
| 2026-06-08 03:26:38 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 03:26:54 +0000 | Guest56 | (~Guest56@2601:645:8101:ead:1598:8824:ff53:79f0) |
| 2026-06-08 03:31:34 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-08 03:35:33 +0000 | Axman6 | (~Axman6@user/axman6) Axman6 |
| 2026-06-08 03:42:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 03:46:38 +0000 | wickedjargon | (~user@2605:8d80:8100:486:a645:88dd:2cda:7f4) (Remote host closed the connection) |
| 2026-06-08 03:47:40 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-08 03:58:50 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 04:03:33 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-06-08 04:08:50 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-08 04:09:05 +0000 | Guest56 | (~Guest56@2601:645:8101:ead:1598:8824:ff53:79f0) (Quit: Client closed) |
| 2026-06-08 04:14:37 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 04:19:19 +0000 | misterfish | (~misterfis@178.230.150.156) (Ping timeout: 272 seconds) |
| 2026-06-08 04:19:22 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 242 seconds) |
| 2026-06-08 04:26:39 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 252 seconds) |
| 2026-06-08 04:30:13 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-08 04:30:23 +0000 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 242 seconds) |
| 2026-06-08 04:34:54 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-08 04:37:32 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-06-08 04:45:56 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 04:52:34 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-08 04:54:17 +0000 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-06-08 04:58:13 +0000 | zalo-rocky | (~flyingzal@186.19.88.142) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-08 05:02:13 +0000 | michalz | (~michalz@185.246.207.221) |
| 2026-06-08 05:02:27 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-08 05:03:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 05:06:35 +0000 | Axman6 | (~Axman6@user/axman6) Axman6 |
| 2026-06-08 05:09:12 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-06-08 05:11:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 05:17:20 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-06-08 05:25:50 +0000 | fp1 | (~Thunderbi@wireless-86-50-141-161.open.aalto.fi) fp |
| 2026-06-08 05:27:39 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 05:31:33 +0000 | Axma32385 | (~Axman6@user/axman6) Axman6 |
| 2026-06-08 05:33:13 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-06-08 05:33:25 +0000 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 245 seconds) |
| 2026-06-08 05:34:05 +0000 | Axma32385 | Axman6 |
| 2026-06-08 05:37:53 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) Enrico63 |
| 2026-06-08 05:39:50 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) CiaoSen |
| 2026-06-08 05:42:37 +0000 | djspacewhale | (~djspacewh@user/djspacewhale) djspacewhale |
| 2026-06-08 05:42:55 +0000 | djspacewhale | (~djspacewh@user/djspacewhale) (Remote host closed the connection) |
| 2026-06-08 05:43:27 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 05:46:06 +0000 | fp1 | (~Thunderbi@wireless-86-50-141-161.open.aalto.fi) (Ping timeout: 241 seconds) |
| 2026-06-08 05:48:02 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-08 05:49:42 +0000 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-06-08 05:55:50 +0000 | Square | (~Square4@user/square) Square |
| 2026-06-08 05:56:13 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...) |
| 2026-06-08 05:59:01 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 06:00:36 +0000 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-06-08 06:03:56 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 251 seconds) |
| 2026-06-08 06:12:49 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-06-08 06:12:52 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 06:16:15 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Client Quit) |
| 2026-06-08 06:17:30 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-08 06:21:40 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-06-08 06:26:34 +0000 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2026-06-08 06:28:40 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 06:35:50 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 259 seconds) |
| 2026-06-08 06:39:55 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) (Quit: Client closed) |
| 2026-06-08 06:40:31 +0000 | Leary | (~Leary@user/Leary/x-0910699) (Remote host closed the connection) |
| 2026-06-08 06:40:49 +0000 | Leary | (~Leary@user/Leary/x-0910699) Leary |
| 2026-06-08 06:46:53 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 06:51:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-08 07:02:35 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 07:04:14 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 256 seconds) |
| 2026-06-08 07:04:22 +0000 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-06-08 07:07:55 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds) |
| 2026-06-08 07:07:58 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-06-08 07:09:53 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-06-08 07:13:05 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-06-08 07:13:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 07:15:10 +0000 | krei-se | (~krei-se@p5098b7b3.dip0.t-ipconnect.de) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2026-06-08 07:17:45 +0000 | krei-se | (~krei-se@photonen.krei.se) krei-se |
| 2026-06-08 07:18:16 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-06-08 07:18:47 +0000 | APic | (apic@chiptune.apic.name) (Ping timeout: 244 seconds) |
| 2026-06-08 07:18:54 +0000 | danza | (~danza@user/danza) danza |
| 2026-06-08 07:29:13 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 07:33:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-06-08 07:35:37 +0000 | APic | (apic@chiptune.apic.name) APic |
| 2026-06-08 07:35:38 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-06-08 07:40:06 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) (Ping timeout: 246 seconds) |
| 2026-06-08 07:40:37 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 276 seconds) |
| 2026-06-08 07:46:12 +0000 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2026-06-08 07:55:08 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) CiaoSen |
| 2026-06-08 07:57:20 +0000 | p3n | (~p3n@217.198.124.246) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-06-08 07:58:07 +0000 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) p3n |
| 2026-06-08 08:00:43 +0000 | danza | (~danza@user/danza) (Ping timeout: 252 seconds) |
| 2026-06-08 08:04:34 +0000 | hc_ | (~hc@mail.hce.li) hc |
| 2026-06-08 08:06:39 +0000 | hc | (~hc@mail.hce.li) (Ping timeout: 252 seconds) |
| 2026-06-08 08:09:28 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-08 08:11:14 +0000 | bandola | (~bandola@c-5eea527c-74736162.cust.telenor.se) |
| 2026-06-08 08:14:57 +0000 | bandola | (~bandola@c-5eea527c-74736162.cust.telenor.se) (Changing host) |
| 2026-06-08 08:14:57 +0000 | bandola | (~bandola@user/bandola) bandola |
| 2026-06-08 08:15:48 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2026-06-08 08:15:48 +0000 | Freakie | (~Freakie@185.45.21.144) |
| 2026-06-08 08:17:19 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-06-08 08:21:41 +0000 | hc_ | hc |
| 2026-06-08 08:22:00 +0000 | emmanuelux | (~em@user/emmanuelux) (Quit: bye) |
| 2026-06-08 08:27:40 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline |
| 2026-06-08 08:28:23 +0000 | ft | (~ft@p508db0ab.dip0.t-ipconnect.de) (Quit: leaving) |
| 2026-06-08 08:37:16 +0000 | <Freakie> | does anyone know where I can find some resources on how major garbage collections are triggered? |
| 2026-06-08 08:45:46 +0000 | vivaldi` | (~ident@user/blackbox) (Quit: vivaldi`) |
| 2026-06-08 08:51:21 +0000 | Digit | (~user@user/digit) (Ping timeout: 248 seconds) |
| 2026-06-08 08:51:30 +0000 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-06-08 08:56:24 +0000 | <merijn> | Freakie: GHC wiki, this https://ezyang.com/jfp-ghc-rts-draft.pdf, and maybe the GHC manual? |
| 2026-06-08 08:57:23 +0000 | <Freakie> | I'll have a look but the places I looked only mentioned as a result of heap overflow, but that doesn't really align with how I understand my experiments to work |
| 2026-06-08 08:59:18 +0000 | <merijn> | Heap overflow? I thought heap as unbounded, sound like you're straight up running the entire system out of memory? |
| 2026-06-08 09:01:15 +0000 | Axma40140 | (~Axman6@user/axman6) Axman6 |
| 2026-06-08 09:04:00 +0000 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 277 seconds) |
| 2026-06-08 09:10:46 +0000 | ss4 | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-06-08 09:11:01 +0000 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2026-06-08 09:11:20 +0000 | Digitteknohippie | Digit |
| 2026-06-08 09:12:22 +0000 | <Freakie> | overflow in the sense that the program needs to allocate more |
| 2026-06-08 09:12:31 +0000 | <tomsmeding> | more than what? |
| 2026-06-08 09:13:11 +0000 | <tomsmeding> | (What is the underlying reason why you want to know about this?) |
| 2026-06-08 09:15:42 +0000 | bandola | (~bandola@user/bandola) (Ping timeout: 256 seconds) |
| 2026-06-08 09:16:07 +0000 | bandola | (~bandola@c-5eea53c4-74736162.cust.telenor.se) |
| 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: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:19:59 +0000 | <Freakie> | that's what I mean by overflow |
| 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:20:08 +0000 | <tomsmeding> | right |
| 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: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:21:16 +0000 | <Freakie> | which is the part I'm trying to understand why |
| 2026-06-08 09:21:29 +0000 | <tomsmeding> | well, GC takes 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: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: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: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:45 +0000 | <Freakie> | because that shouldn't have any effect on the allocation throughput |
| 2026-06-08 09:24:01 +0000 | <tomsmeding> | GC runs when the nursery is exhausted |
| 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:11 +0000 | <Freakie> | isn't that only minor gc? |
| 2026-06-08 09:24:19 +0000 | <Freakie> | it should only be minor |
| 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: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:30:13 +0000 | <tomsmeding> | there's one when threads seem to be deadlocked, for example (scheduleDetectDeadlock()) |
| 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:32:09 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 261 seconds) |
| 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:49 +0000 | <merijn> | If data never leaves the nursery than a major GC won't ever be needed |
| 2026-06-08 09:33:38 +0000 | chele | (~chele@user/chele) chele |
| 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:34:49 +0000 | acidjnk | (~acidjnk@p200300d6e700e514a755b21df9febc31.dip0.t-ipconnect.de) acidjnk |
| 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:35:29 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) (Quit: Client closed) |
| 2026-06-08 09:35:46 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) |
| 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:36:16 +0000 | <merijn> | So in that sense it seems very obvious that bigger nursery correlates with fewer major GC |
| 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:33 +0000 | <merijn> | At least for some workflows |
| 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: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:48:56 +0000 | <merijn> | major GC works on everything afaik? |
| 2026-06-08 09:49:04 +0000 | <merijn> | It makes no sense to only work on the oldest generation |
| 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: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:50:59 +0000 | <Freakie> | oh you mean |
| 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:53:30 +0000 | <Freakie> | less space on average* |
| 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 10:05:05 +0000 | Axma40140 | (~Axman6@user/axman6) (Ping timeout: 245 seconds) |
| 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: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:21:27 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 248 seconds) |
| 2026-06-08 10:21:59 +0000 | misterfish | (~misterfis@178.230.99.247) misterfish |
| 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:23:55 +0000 | vivaldi` | (~ident@user/blackbox) blackbox |
| 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:24:37 +0000 | <vivaldi`> | hello haskellians! |
| 2026-06-08 10:25:01 +0000 | <vivaldi`> | I don't do haskell. should I try it? |
| 2026-06-08 10:26:10 +0000 | <Freakie> | depends on your needs/interests I think |
| 2026-06-08 10:27:29 +0000 | <vivaldi`> | could be fun to learn :) |
| 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:28:14 +0000 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) (Ping timeout: 256 seconds) |
| 2026-06-08 10:31:11 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-08 10:38:49 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) (Quit: Client closed) |
| 2026-06-08 10:39:09 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) |
| 2026-06-08 10:40:08 +0000 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) NinjaTrappeur |
| 2026-06-08 10:41:29 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-08 10:41:30 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-08 10:41:30 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-08 10:50:40 +0000 | glguy | (glguy@libera/staff/glguy) (Read error: Connection reset by peer) |
| 2026-06-08 10:51:04 +0000 | glguy | (glguy@libera/staff/glguy) glguy |
| 2026-06-08 10:56:04 +0000 | xstill_ | (xstill@fimu/xstill) xstill |
| 2026-06-08 10:56:18 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 244 seconds) |
| 2026-06-08 10:58:52 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) (Quit: KVIrc 5.2.8 Quasar http://www.kvirc.net/) |
| 2026-06-08 10:59:21 +0000 | misterfish | (~misterfis@178.230.99.247) (Ping timeout: 252 seconds) |
| 2026-06-08 11:01:43 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) CiaoSen |
| 2026-06-08 11:06:30 +0000 | Square2 | (~Square@user/square) Square |
| 2026-06-08 11:07:29 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) (Quit: Client closed) |
| 2026-06-08 11:07:46 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) |
| 2026-06-08 11:09:38 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) Enrico63 |
| 2026-06-08 11:19:37 +0000 | cipherrot | (~jez@user/petrichor) (Ping timeout: 248 seconds) |
| 2026-06-08 11:20:24 +0000 | ss4 | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2026-06-08 11:20:31 +0000 | petrichor | (~jez@user/petrichor) petrichor |
| 2026-06-08 11:24:36 +0000 | comerijn | (~merijn@77.242.116.150) merijn |
| 2026-06-08 11:26:02 +0000 | Freakie | (~Freakie@185.45.21.144) (Ping timeout: 245 seconds) |
| 2026-06-08 11:27:24 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 253 seconds) |
| 2026-06-08 11:27:24 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 253 seconds) |
| 2026-06-08 11:28:32 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) (Ping timeout: 245 seconds) |
| 2026-06-08 11:28:38 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-08 11:36:36 +0000 | Square2 | (~Square@user/square) (Ping timeout: 244 seconds) |
| 2026-06-08 11:41:45 +0000 | caryhartline | (~caryhartl@159.26.119.68) (Read error: Connection reset by peer) |
| 2026-06-08 11:47:53 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-08 11:50:58 +0000 | comerijn | (~merijn@77.242.116.150) (Ping timeout: 256 seconds) |
| 2026-06-08 11:59:50 +0000 | xnyhps__ | (~xnyhps@s.xnyhps.nl) (Remote host closed the connection) |
| 2026-06-08 12:00:05 +0000 | xnyhps_ | (~xnyhps@s.xnyhps.nl) |
| 2026-06-08 12:05:13 +0000 | comerijn | (~merijn@77.242.116.146) merijn |
| 2026-06-08 12:07:40 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 252 seconds) |
| 2026-06-08 12:07:59 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 272 seconds) |
| 2026-06-08 12:08:55 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) (Ping timeout: 245 seconds) |
| 2026-06-08 12:09:43 +0000 | xnyhps_ | (~xnyhps@s.xnyhps.nl) (Ping timeout: 276 seconds) |
| 2026-06-08 12:10:17 +0000 | xnyhps | (~xnyhps@s.xnyhps.nl) |
| 2026-06-08 12:11:40 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-08 12:11:41 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-08 12:11:41 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-08 12:22:15 +0000 | haritz | (~hrtz@140.228.70.141) |
| 2026-06-08 12:22:16 +0000 | haritz | (~hrtz@140.228.70.141) (Changing host) |
| 2026-06-08 12:22:16 +0000 | haritz | (~hrtz@user/haritz) haritz |
| 2026-06-08 12:24:30 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-06-08 12:32:24 +0000 | ouilemur | (~jgmerritt@user/ouilemur) (Ping timeout: 245 seconds) |
| 2026-06-08 12:33:54 +0000 | user363627 | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2026-06-08 12:34:13 +0000 | user363627 | (~user@user/user363627) user363627 |
| 2026-06-08 12:37:46 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 245 seconds) |
| 2026-06-08 12:39:08 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) Enrico63 |
| 2026-06-08 12:45:57 +0000 | xff0x | (~xff0x@ai070051.d.east.v6connect.net) |
| 2026-06-08 12:47:00 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) (Quit: Client closed) |
| 2026-06-08 12:47:27 +0000 | Freakie | (~Freakie@185.45.21.144) |
| 2026-06-08 12:48:16 +0000 | <yin> | i think i finally surrendered to StrictData |
| 2026-06-08 12:53:52 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) |
| 2026-06-08 12:56:42 +0000 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-06-08 12:57:00 +0000 | user363627 | (~user@user/user363627) (Ping timeout: 268 seconds) |
| 2026-06-08 12:58:18 +0000 | <janus> | in the STGi, is evaluation always to normal form? |
| 2026-06-08 12:58:45 +0000 | <janus> | i am wondering why it starts out with 'Eval main' and then evaluates 'add 1# 2#' all the way to '3#' |
| 2026-06-08 13:01:13 +0000 | <janus> | i suppose i am just wondering why, in a pure lazy language, there needs to be a difference between Case and Eval |
| 2026-06-08 13:02:44 +0000 | <janus> | i've seen that that Case always only matches on the outer level, so if main is an Int#, i suppose it has to get evaluated to 3# because anything else wouldn't be a constructor of Int# |
| 2026-06-08 13:08:54 +0000 | <janus> | maybe 'main' is a bit different in STGi in that it can be evaluated to WHNF while in Haskell i don't even know if it makes sense to talk about WHNF of 'IO ()' |
| 2026-06-08 13:12:14 +0000 | <ski> | `return undefined' is different from `undefined' |
| 2026-06-08 13:12:35 +0000 | <ski> | (also, `main' has type `IO a', for any `a' you like) |
| 2026-06-08 13:15:22 +0000 | DetourNe- | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2026-06-08 13:15:40 +0000 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2026-06-08 13:17:35 +0000 | DetourNe- | DetourNetworkUK |
| 2026-06-08 13:21:49 +0000 | <janus> | hmm, so I suppose main with type `IO a` is evaluated until the last `pure`, but that `a` is not necessarily evaluated. Because I can do `pure undefined` without having it crash at runtime |
| 2026-06-08 13:22:50 +0000 | <janus> | This also shows the difference with simply `undefined` at the end since that _does_ crash |
| 2026-06-08 13:24:32 +0000 | <janus> | Right ok. So since STGi doesn't have any special monad handling, it has to teach main differently. And it just decides to evaluates main to WHNF even though that is not applicable to GHC's main |
| 2026-06-08 13:25:37 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline |
| 2026-06-08 13:27:07 +0000 | <janus> | s/teach/handle/ |
| 2026-06-08 13:27:44 +0000 | rekahsoft | (~rekahsoft@2605:8d80:1520:40b8:7f13:d56c:3912:7b7a) rekahsoft |
| 2026-06-08 13:31:49 +0000 | __monty__ | (~toonn@user/toonn) (Ping timeout: 244 seconds) |
| 2026-06-08 13:34:01 +0000 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-06-08 13:38:43 +0000 | TwinAdam | (~TwinAdam@user/adamsaunders) (Ping timeout: 264 seconds) |
| 2026-06-08 13:39:59 +0000 | <janus> | oh, the readme does say "Note that the WHNF part makes case strict, and indeed it is the only construct that does evaluation." |
| 2026-06-08 13:39:59 +0000 | TwinAdam | (~TwinAdam@user/adamsaunders) adamsaunders |
| 2026-06-08 13:41:07 +0000 | <janus> | probably not entirely true because as written, main is also evaluted even though it has no case |
| 2026-06-08 13:45:21 +0000 | ouilemur | (~jgmerritt@user/ouilemur) ouilemur |
| 2026-06-08 13:47:06 +0000 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2026-06-08 13:52:15 +0000 | xff0x | (~xff0x@ai070051.d.east.v6connect.net) (Quit: xff0x) |
| 2026-06-08 13:52:43 +0000 | <comerijn> | janus: The evaluation of main is (conceptually) external to your code, though |
| 2026-06-08 13:52:57 +0000 | <comerijn> | i.e., that's the RTS' purview which is not constrained by the language definition |
| 2026-06-08 13:57:21 +0000 | <comerijn> | janus: At the STG level `IO a` is just a function `RealWorld# -> (a, RealWorld#)` (where `RealWorld#` is a builtin in the compiler) |
| 2026-06-08 13:57:46 +0000 | <comerijn> | janus: So at the STG level running IO/main is just a matter of "pass an argument, force the resulting tuple" |
| 2026-06-08 14:02:20 +0000 | <janus> | comerijn: ok, and 'pure' corresponds to the tuple constructor? because it crashes if the tuple is undefined, but it doesn't crash if the 'a' is undefined... |
| 2026-06-08 14:03:31 +0000 | <janus> | i suppose i could make an STGi program with a tuple construction, and then it shouldn't ever evaluated the 'a' thunk |
| 2026-06-08 14:07:05 +0000 | rekahsoft | (~rekahsoft@2605:8d80:1520:40b8:7f13:d56c:3912:7b7a) (Ping timeout: 248 seconds) |
| 2026-06-08 14:08:49 +0000 | ystael | (~ystael@user/ystael) ystael |
| 2026-06-08 14:10:40 +0000 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) epolanski |
| 2026-06-08 14:11:00 +0000 | <ski> | janus : "is evaluated until the last `pure`" -- not really. it would also stop at a `(>>=)' |
| 2026-06-08 14:12:15 +0000 | xff0x | (~xff0x@2405:6580:b080:900:7bda:8dd9:d259:e21b) |
| 2026-06-08 14:17:11 +0000 | gehmehgeh | (~user@user/gehmehgeh) gehmehgeh |
| 2026-06-08 14:19:01 +0000 | gmg | (~user@user/gehmehgeh) (Ping timeout: 245 seconds) |
| 2026-06-08 14:20:06 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2026-06-08 14:20:34 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-08 14:23:38 +0000 | gehmehgeh | gmg |
| 2026-06-08 14:24:29 +0000 | xff0x | (~xff0x@2405:6580:b080:900:7bda:8dd9:d259:e21b) (Ping timeout: 245 seconds) |
| 2026-06-08 14:25:36 +0000 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) machinedgod |
| 2026-06-08 14:25:49 +0000 | <janus> | ski: how would it ever get beyond the first line of the 'do' notation the 'main' definition if it stops at the first >>=? |
| 2026-06-08 14:26:00 +0000 | <janus> | if i do echo -e 'import Debug.Trace ; main = traceM "hi" >>= \() -> pure undefined' > /tmp/B.hs |
| 2026-06-08 14:26:13 +0000 | <janus> | and i run that program, i see "hi" but no exception |
| 2026-06-08 14:27:09 +0000 | <ski> | janus : after evaluation to WHNF, it executes the resulting `IO'-action, which may in turn trigger further execution (and dependent evaluation) |
| 2026-06-08 14:27:45 +0000 | <ski> | and yea, the monadic result value of `main' is ignored, so that `undefined' is never evaluated |
| 2026-06-08 14:29:56 +0000 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2026-06-08 14:29:58 +0000 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) CloneOfNone |
| 2026-06-08 14:30:12 +0000 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-06-08 14:30:52 +0000 | CloneOfNone_ | (~CloneOfNo@user/CloneOfNone) (Ping timeout: 265 seconds) |