[00:27] *** MasterDuke left [01:02] *** Util_ left [02:16] *** frost joined [03:19] i'll donate the MVM_inline_cache_get_kind implementation [03:41] ¦ MoarVM/new-disp: 45fb8e3eb5 | (Timo Paulssen)++ | 2 files [03:41] ¦ MoarVM/new-disp: allow kind of inline cache entry to be determined outside of inline_cache.c [03:41] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/45fb8e3eb5 [03:42] https://gist.github.com/timo/36c7b304a2917f67233c3ef910bd395d [03:43] [timo@kritter nqp]$ grep -c -B1 "dispatch program" /tmp/testrun.speshlog.txt [03:43] 449 [03:43] [timo@kritter nqp]$ grep -B1 "dispatch program" /tmp/testrun.speshlog.txt | grep -c "Common DP" [03:43] 242 [03:43] this is a random nqp test file i grabbed: t/nqp/102-multidim.t [03:44] so out of 449 times a dispatch program appears for a monomorphic dispatch it'll be the one that's just "guard for the first arg being of a given type, and being concrete, then load that argument, then setting that argument as the result_o [03:47] not really all that helpful, just 1) stealable code to grab the corresponding MVMDispProgram for a given dispatch_* instruction in a spesh graph, and a really common and very short disp program that could be the first target to get a full disp program compiled to spesh ops and such [03:52] and of course the patch where i did that the last time there's other important stuff like splitting the version of incoming arguments and all that jazz [03:59] *** Util joined [05:37] *** frost left [06:04] *** reportable6 joined [06:38] *** frost joined [06:52] *** patrickb joined [06:53] *** squashable6 left [06:55] *** squashable6 joined [07:00] *** MasterDuke joined [07:41] good *, #moarvm [07:45] *** frost left [09:10] *** Kaipi left [09:12] *** Kaiepi joined [09:14] moarning o/ [09:14] I see the night shift has delivered :) [09:14] timo++ [09:15] \o [09:22] *** linkable6 joined [09:23] *** linkable6 left [09:37] *** frost joined [09:38] this is odd. if i'm on my branch that correctly excludes DEPRECATED ops from being genned by update_ops.raku, and do in fact regen them, the nqp build breaks [09:41] with `moarop bindexcategory is not void`. it's not a problem with bindexcategory itself, but the interaction of `MAST::Ops.WHO<@offsets>` and `MAST::Ops.WHO<@values>` [09:42] the offset for that op is the same in both cases, but the value at the offset is different (the values list is shorter with deprecated ops excluded, not surprisingly) [09:43] Ah wow, `make test` builds with spesh and JIT in NQP, just not expr JIT, probably due to the sp_getarg_* impl needing updating [09:45] "such wow | so JIT | faster" ? [09:45] does rakudo build (faster)? [09:46] Didn't try yet :) [09:46] Was just seeing if it's obvious (to me) how to update the expr JIT [09:46] It's not [09:52] MasterDuke: From 60.8s to 54.3s on my machine [09:52] Note it's doing no optimization around dispatch programs yet [09:52] nice [09:53] So no spesh linking, no inlining, etc. [09:53] Nice it makes it through CORE.setting though [09:54] Hm, some SEGVs in make test [10:15] ¦ MoarVM/new-disp: 8471f1e008 | (Jonathan Worthington)++ | src/spesh/args.c [10:15] ¦ MoarVM/new-disp: Fix overflow when processing long arg captures [10:15] ¦ MoarVM/new-disp: [10:15] ¦ MoarVM/new-disp: This would not come up under the previous design, where anything that [10:15] ¦ MoarVM/new-disp: was called with a flattening callsite would refuse to spesh in the first [10:15] ¦ MoarVM/new-disp: place and other maximums protected this code. Now, however, we need to [10:15] ¦ MoarVM/new-disp: cope with the input capture being larger in size. Rather than refusing [10:15] ¦ MoarVM/new-disp: it with a size check, permit it when we have a slurpy positional. [10:15] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/8471f1e008 [10:15] Less SEGVs in make test [10:16] .oO( uh-oh, here comes the fewrer... ) [10:21] :-) [10:30] Oh wow, make spectest on new-disp takes so long apparently 'cus a small number of tests take forever [10:30] and probably eat your memory as well :-) [10:31] Curiously not [10:31] One had eaten 1.5% of the my RAM, the other 0.3% [10:31] jnthnwrthngtn: try t/spec/S05-modifier/ignorecase.t [10:32] ah, just infinilooping? or did they finish in the end ? [10:35] ¦ MoarVM/new-disp: 562249e6a1 | (Jonathan Worthington)++ | src/jit/core_templates.expr [10:35] ¦ MoarVM/new-disp: Disable some expr JIT templates for now [10:35] ¦ MoarVM/new-disp: [10:35] ¦ MoarVM/new-disp: They need updating for the new calling conventions. [10:35] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/562249e6a1 [10:35] ¦ MoarVM/new-disp: 0d5e398d93 | (Jonathan Worthington)++ | src/core/frame.c [10:35] ¦ MoarVM/new-disp: Switch spesh back on [10:35] ¦ MoarVM/new-disp: [10:35] ¦ MoarVM/new-disp: While running it with the various spesh stressing flags may turn up [10:35] ¦ MoarVM/new-disp: something, we don't (at least with the expression JIT temporarily [10:35] ¦ MoarVM/new-disp: limited) seem to fail anything more than with spesh turned off. Note [10:35] ¦ MoarVM/new-disp: that this doesn't do the integration of dispatch programs with spesh [10:35] ¦ MoarVM/new-disp: (and thus there's no spesh linking or inlining at present), so only a [10:35] ¦ MoarVM/new-disp: small speedup is to be expected from this. [10:35] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/0d5e398d93 [10:35] lizmat: Most of them did eventually finish, after some ran for 3 minutes I cancelled them [10:36] dogbert17: ooh, that's an interesting one indeed. [10:36] yeah, snails pace :) [10:37] *** evalable6 left [10:40] perf top shows a massive amount of time spent in MVM_disp_program_run [10:40] *** evalable6 joined [10:41] sigh, why does callgrind not give me any output [10:42] oh, because you can't run `valgrind --tool=callgrind ./rakudo-m ...` 'cus it does execve or whatever [10:51] Ah right, I never imposed an upper limit on the level of polymorphism at a given dispatch cache site. Of course going widly polymorphic may expose a bug [10:54] So putting in a limit is easy. What's a bit surprising is that my first guess at the limit causes a huge slowdown in CORE.setting compilation [10:55] 42 wasn't the correct answer? [10:55] It might yet prove to be :P [11:10] OK, I think t/spec/MISC/bug-coverage.t is a real infilooper [11:11] ¦ MoarVM/new-disp: 692fad885d | (Jonathan Worthington)++ | 2 files [11:11] ¦ MoarVM/new-disp: Enforce an upper limit on inline cache size [11:11] ¦ MoarVM/new-disp: [11:11] ¦ MoarVM/new-disp: This is a rather higher number than I expected to end up with, and [11:11] ¦ MoarVM/new-disp: warrants further investigation. With anything much smaller than this, we [11:11] ¦ MoarVM/new-disp: see a significant slowdown in CORE.setting compilation time. [11:11] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/692fad885d [11:14] m: sub (uint8 $x) { Nil until $x; }(2) [11:14] rakudo-moar b4d33982a: OUTPUT: «(timeout)» [11:15] Uh. So how does this test not hang on master if it times out there too? [11:15] m: sub (uint8 $x) { say $x; Nil until $x; }(2) [11:15] rakudo-moar b4d33982a: OUTPUT: «(timeout)2␤» [11:16] Test file wasn't touched for over a year [11:20] weird. it does complete ok even if you just run it manually (i.e., `./rakudo-m -I lib/ t/spec/MISC/bug-coverage.t`) [11:20] What if you run just the thing I evaluated? [11:21] hang [11:21] :S [11:21] If you look at the bytecode it compiles into it's obviously wrong [11:21] I just don't get how the test can possibly pass on master [11:22] perf says it's spending all its time in MVM_interp_run [11:22] Yeah, it code-gens a loop where it reads an uninitialized register [11:23] Maybe 'cus it fails to emit an instruction to coerce the unsinged value into a full-width one for the test or something [11:23] you've already looked at the MVM_dump_bytecode output? [11:24] it hangs for me with a signed int also [11:24] Yes [11:24] OK, well, not a new-disp specific bug, anyway [11:26] hangs on all unsigned (sized or not), succeeds on signed unsized or size 64 [11:37] *** patrickb left [11:37] *** patrickb joined [11:39] *** patrickb left [11:39] *** patrickb joined [11:41] *** patrickb left [11:41] *** patrickb joined [11:43] *** patrickb left [11:43] *** patrickb joined [11:45] *** patrickb left [11:45] *** patrickb joined [11:49] *** patrickb left [11:49] *** patrickb joined [11:51] *** patrickb left [11:52] *** patrickb joined [11:53] *** patrickb left [11:54] *** patrickb joined [11:55] *** patrickb left [11:56] *** patrickb joined [11:57] *** patrickb left [11:58] *** patrickb joined [11:58] *** patrickb left [12:02] *** reportable6 left [12:39] *** Altai-man left [12:39] *** Altai-man joined [12:47] *** linkable6 joined [12:54] jnthnwrthngtn: are we, at this point, expecting MVM_SPESH_NODELAY=1 and MVM_SPESH_BLOCKING=1 to SEGV? [12:57] It might. [12:57] I didn't try it [12:58] Thread 1 "moar" received signal SIGSEGV, Segmentation fault. [12:58] But I'd not be surprised if there's more things that need a fixup [12:58] 0x00007ffff7917ba2 in handle_bind_failure (failure_record=, tc=0x555555559e40) at src/core/callstack.c:382 [12:58] 382 ice->run_dispatch(tc, ice_ptr, ice, id, callsite, args, &(failure_record->flag), [12:58] Hmm [12:58] What if you disable JIT? [12:58] MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./rakudo-m -Ilib t/02-rakudo/12-proto-arity-count.t # SEGV for me [12:59] it still fails [12:59] ¦ MoarVM/new-disp: 2d2f0183c8 | (Jonathan Worthington)++ | src/disp/syscall.c [12:59] ¦ MoarVM/new-disp: Add a couple of lexical capture related syscalls [12:59] ¦ MoarVM/new-disp: [12:59] ¦ MoarVM/new-disp: These will be used to eliminate a couple of Rakudo extops. [12:59] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/2d2f0183c8 [13:00] with MVM_JIT_DISABLE=1 that is [13:02] yeah, exciting! [13:03] rid us of these extops [13:03] perhaps something for our intrepid bughunters timo and nine :) [13:04] At least 3 more really have to go away [13:05] Although getting rid of the invocation protocol is...quite a bit of effort [13:05] the thing that also has fallback and call-me, right? [13:05] oh but also coercers and i guess junctions would also want to go in there? [13:06] can you imagine using dispatchers to make junction autothreading faster [13:07] I think I already did make it an iota less bad when it's a multi failover - or at least, we avoid one round of flatten/slurp along the way [13:07] timo: is there any way to use your appimages to run scripts on the filesystem? [13:10] timo: I'm glancing over your dispatch program to ops work; I note the problem about it deopting to the wrong place, but I think that's a case of marking it :predeoptonepoint instead of :deoptonepoint [13:10] (Which I'm trying to do now, but it blows up, though I can guess why...) [13:13] :+1: glad to see it be of use, even if just to skip over some tedious switch/case writing or something [13:15] *** leedo_ joined [13:17] Hm, I can't actually see why putting the deopt point before it blows up, actually. We don't even deopt yet. [13:18] *** discord-raku-bot left [13:18] *** leedo left [13:34] Ah, turns out at least partly 'cus code-gen wasn't aware of pre/post deopt indexes so shoved it in the wrong place [13:38] ¦ MoarVM/new-disp: 48b6f4e564 | (Jonathan Worthington)++ | 6 files [13:38] ¦ MoarVM/new-disp: Mark dispatch_* as pre-deopt instructions [13:38] ¦ MoarVM/new-disp: [13:38] ¦ MoarVM/new-disp: That is, we should deopt to before them, not after them, since if we [13:38] ¦ MoarVM/new-disp: fail to meet the guards then we need to attempt the dispatch via the [13:38] ¦ MoarVM/new-disp: dispatch mechanism (maybe recording a new program) in order to put the [13:38] ¦ MoarVM/new-disp: dispatch into effect. [13:38] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/48b6f4e564 [13:44] https://github.com/MoarVM/MoarVM/pull/1518 has been updated and works fine. now after a regen and nqp rebuild+rebootstrap, src/vm/moar/stage0/MASTOps.moarvm decreases in size from 1257384 to 1210008 [13:44] m: say 1257384 - 1210008 [13:44] rakudo-moar b4d33982a: OUTPUT: «47376␤» [13:48] ¦ MoarVM/new-disp: adfb5cd4b5 | (Timo Paulssen)++ (committed by Jonathan Worthington) | 3 files [13:48] ¦ MoarVM/new-disp: Stash away spesh correlation ID earlier [13:48] ¦ MoarVM/new-disp: [13:48] ¦ MoarVM/new-disp: So that it will always be the correct one. [13:48] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/adfb5cd4b5 [13:58] i don't think https://github.com/MoarVM/MoarVM/pull/1518 will cause any new/more rebasing problems [14:10] m: say (1257384 - 1210008) / 1257384 [14:10] rakudo-moar b4d33982a: OUTPUT: «0.037678␤» [14:10] i'll take it [14:15] it'll be even greater after new-disp because it deprecates a ton more and only adds a couple [14:18] m: say 1257384 - 1177856; say (1257384 - 1177856) / 1257384 [14:18] rakudo-moar b4d33982a: OUTPUT: «79528␤0.0632488␤» [14:19] cool [14:19] ^^^ i cherry-picked the commit into new-disp and re-ran it [14:22] jnthnwrthngtn: if that Nil until $x thing reads an uninitialized register, maybe it just so happens to find a value there that lets it continue? And what it finds there is influenced by what other code is run [14:29] any reason not to merge https://github.com/MoarVM/MoarVM/pull/1518 ? [14:33] nine: don't we zero-initialize a frame's work area before entering? [14:33] nine: Yes, I think that's what's going on [14:35] timo: Only pointer regs (.o and .s) [14:35] iirc, anyway [14:36] Oh, alternatively, maybe we do zero everything but we had a prior bit of code we generated poke a non-zero into that [14:36] It looks like a mis-compile somewhere in the QAST -> MAST though [14:37] well, we null-initialize .o and .s registers by copying vmnull in there [14:45] i'm sorry i still haven't put the recursion limit into spesh's inliner [14:48] *** frost left [15:30] ¦ MoarVM: dyknon++ created pull request #1519: Stream Decoder: Disallow incomplete code at EOF [15:30] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1519 [15:55] i put the type of object in the program dump output. is it always MVMObject or is it sometimes an STable in the gc_constants? i assume it can be [15:56] Load collectable constant at index 2 (of type NQPRegex) into temporary 1 [15:56] this is what it looks like [16:02] random peek into core setting compilation shows a good number of "guard argument type concrete, guard literal string argument, set value from collectible constant, return result from that" [16:03] I suspect that's a ton of sinks being turned into very little :) [16:04] in these cases it's mostly (or always?) an NQPRoutine that gets returned [16:05] maybe i should also output the name and cuuid or perhaps filename/line number of the routine there [16:05] this is calls from !reduce for example [16:05] could that be the surprisingly megamorphic one perhaps? [16:42] https://gist.github.com/timo/f283631677a9125b07c57d1236b4dd35 - there we go [16:43] clearly this is the self."$name"() thing [16:43] if !reduce could get inlined into the regex it belongs to it'd make that dispatch go away immediately, cool. [16:43] do we call !reduce from inside the regex code? [16:44] if so that'd do it i expect [16:46] That segfault in t/02-rakudo/12-proto-arity-count.t is because we're dereferencing a NULL. The NULL comes from the disp_inline_cache (most entries are NULL). [17:06] Ok, so there is a dispatch inline cache per static frame. The desired cache slot is found via mapping the current position in the bytecode. This position will obviously be different in speshed code. [17:06] So we're gonna need sp_ versions of all ops that access this cache. These versions will take either the original bytecode position (found in an annotation) or a slot number as a literal. [17:07] how many ops is that? [17:07] Indeed, ops like sp_getlexstatic_o and sp_dispatch_o already exist which take byte bytecode position as argument. assertparamcheck seems missing [17:09] Oh, no, they actually take the slot number directly. There's an MVM_disp_inline_cache_get_spesh version for that [17:11] nine: That analysis makes sense, fwiw [17:11] It seems that MVM_spesh_manipulate_split_version is pretty busted [17:12] Or at least, it looks most likely to be the guilty party in why we're getting odd things going on with versions when translating dispatch programs into ops [17:13] ¦ MoarVM/compile-basic-disp-program: aef5408a40 | (Jonathan Worthington)++ | 5 files [17:13] ¦ MoarVM/compile-basic-disp-program: Start to translate dispatch programs in spesh [17:13] ¦ MoarVM/compile-basic-disp-program: [17:13] ¦ MoarVM/compile-basic-disp-program: This gets us able to translate some dispatch programs with basic guards [17:13] ¦ MoarVM/compile-basic-disp-program: and producing a result which is a value. Thanks to timo++ for a first [17:13] ¦ MoarVM/compile-basic-disp-program: draft, which I borrowed some of the code here from. [17:13] ¦ MoarVM/compile-basic-disp-program: review: https://github.com/MoarVM/MoarVM/commit/aef5408a40 [17:14] I'm pretty sure I'm too tired to figure it out now, but I suspect it's much too naive [17:16] I think it should be walking successors up to a PHI [17:16] Instead it's trying to get away with visiting dominance children [17:21] ooooooh yeeaaahhhh [17:29] ¦ MoarVM/new-disp: 381d78d8a6 | (Stefan Seifert)++ | 6 files [17:29] ¦ MoarVM/new-disp: Fix segfaults caused by accessing wrong disp inline cache slot in speshed code [17:29] ¦ MoarVM/new-disp: [17:29] ¦ MoarVM/new-disp: There is a dispatch inline cache per static frame. The desired cache slot is [17:29] ¦ MoarVM/new-disp: found via mapping the current position in the bytecode. This position will be [17:29] ¦ MoarVM/new-disp: different in speshed code. So we need a spesh version of assertparamcheck that [17:29] ¦ MoarVM/new-disp: already knows the correct cache slot to query. [17:29] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/381d78d8a6 [17:30] This gets us further, but it still ends in a segfault. This time in build_cfg [17:49] i see a boatload of unbox dispatches are being compiled, that's cool [17:51] 9896086 looks a bit high for an ins literal [18:04] *** reportable6 joined [18:06] Huh...we're processing the MVMOpInfo of param_op_s, but according to the bytecode dump, there's no such instruction in the static frame... [18:12] 1017 aborted disp compile due to load constant obj or string [18:13] i'm assuming the programs that this would unlock have some other ops that would currently abort compilation tho [18:15] I think we're stumbling over a dispatch_o instruction with 353 arguments [18:19] https://gist.github.com/timo/94003db670409f65678e77f87024a70f [18:19] oh? that sounds like .. a lot :D [18:19] ¦ MoarVM/new-disp: 02361112b8 | (Stefan Seifert)++ | src/spesh/graph.c [18:19] ¦ MoarVM/new-disp: Fix segfault caused by int overflow when builindg cfg in spesh [18:19] ¦ MoarVM/new-disp: [18:19] ¦ MoarVM/new-disp: dispatch_* instructions have a variable number of arguments that can get quite [18:19] ¦ MoarVM/new-disp: large. In the case of a call with 353 arguments, we overflowed arg_size causing [18:19] ¦ MoarVM/new-disp: us to jump to a weird location in the bytecode when processing. Use a more [18:19] ¦ MoarVM/new-disp: appropriate int size. [18:19] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/02361112b8 [18:20] well spotted [18:20] This gets us through t/02-rakudo/12-proto-arity-count.t with MVM_SPESH_NODELAY=1 and MVM_SPESH_BLOCKING=1 :) [18:20] i'm kind of a tiny bit annoyed we don't have anything in place that automatically generates a "give me the string name for a given enum value" function per enum [18:20] dogbert17: done :D [19:04] *** linkable6 left [19:04] *** evalable6 left [19:04] *** evalable6 joined [19:07] *** linkable6 joined [19:22] * timo put in "load object or string to temporary" instruction, including creating new temporaries if necessary [19:31] why do i get so many segfaults :) :) [19:32] 326 assert(deopt_idx < 0 || seen_deopt_idx); [19:32] this asplodes [19:32] (wasn't segfault, was abort) [19:33] i cherry-picked the last two commits from new-disp, i was thinking that should fix all possible things! [19:41] so what is the state of the GC in MoarVM? It's still stop the world right? And one thread doing the GC, no ? [19:42] every thread can participate, as long as they aren't blocked [19:43] but yes, everything stops before gc starts and everything resumes once all gc is done [19:45] and we don't have a way of saying: forget about GC for this run of a program, right? [19:51] not really, no. there's a flag that can be set internally to moarvm that just allocates everything in the gen2, that leads to rather massive memory increase depending on your workload, though [19:51] would that make sense for oneliners ? [19:52] or is it a MoarVM compile time flag ? [19:55] it's run-time, but we don't have anything exposed to set it yet [19:55] what were you thinking of? a flag to rakudo's commandline? [20:11] yeah, would be nice to experiment with, see if it reduces runtime in some situations? [20:17] the trivial way to set that up crashes, unfortunately [20:25] <[Coke]> everyone++ .for new-disp work! [20:26] indeed! everyone++ [20:36] lizmat: remember that even one liners run the full blown compiler to compile that line. And that is gonna eat quite some memory. [20:36] ah, yes... hmmm [20:37] how often do we run the gc during a short one-liner? [20:37] The GC is also pretty fast. And we can re-use the memory it reclaims, so we don't have to ask the operating system for more all the time [20:37] just have one huge ring buffer and assume when we've re-reached the beginning the data there is probably not in use any more [20:37] Getting definitive number would be intersting though :) [20:38] The gen2 default flag cannot be active all the time. There are parts of MoarVM which don't work when that's active [20:39] For just getting numbers one could increase the nurseey size until no more GC happens [20:57] *** Kaiepi left [21:00] *** Kaiepi joined [21:03] has anybody tried the one liner in question and looked where the allocations come from? i would assume from just .lc on the big list of strings [21:12] *** Kaiepi left [21:13] nine: Our GC is decent, but for real-time code it has a couple of difficult behaviors: variability in duration (especially from the mix of no GC versus nursery GC versus full GC), uncontrolled entry (which can be fudged a bit by requesting GC start at a known point), and non-trivial minimum length (which can eat up a bunch of time in the RT loop whenever it triggers). [21:20] with a gen2 of possibly unbounded size, not much we can do unless we get incremental gc to work, and then memory size may grow infinitely as a trade-off [21:32] timo: There are a fair number of cases that I can give a bound on memory used per second; it might be nice to be able to tune something like an incremental GC for that. [21:33] timo: For example, in real-time gaming, I might be able to negotiate the rate and size of world updates with the server (this isn't a theoretical; several engines do this so that lower-bandwidth players can play at all). [21:36] i guess that's fair. just have to make sure the gc can keep up with the rate of new garbage appearing [21:37] i guess "realtime" isn't something you'd just slap onto something and expect to be done with it [21:41] i don't think we're doing any compensation for not-full nurseries when GC is triggered either by a different thread or by forcing GC directly [21:41] *** Kaiepi joined [21:42] that can lead to a thread that slowly fills its nursery to put stuff in the old generation too early [21:45] <[Coke]> how to force rakudo build of new-disp to use latest moarvm/nqp? just --gen-nqp=new-disp says "yes, you have that." [21:48] i recommend cd-ing into the folders and just git pull-ing [21:52] timo: Yeah, that's part of why (for example) requesting a GC after processing each world update is suboptimal -- because it's going to cause other threads to promote more than they should, which means worse full GC. [21:53] <[Coke]> timo: ... yah, that doesn't work. have to also kill install/ ? Eff it, will just nuke it and start over. :| [21:59] oh, i see [21:59] well, i always cd in and "make install" anyway [22:00] <[Coke]> in the subdirs? oh [22:00] japhb: since we have per-thread nurseries, i could imagine an API to get nursery status would be like "i give you a native num array and you fill it with the percentages", but nurseries can be different sizes, we create further threads with smaller nurseries, so perhaps an array of ints with filled, size, filled, size, filled, size [22:02] What causes a nursery to grow, and how much does it grow? And can you specify a minimum size for new thread nurseries? [22:03] I guess there's also the problem that the special threads are going to grow differently than the general threads [22:04] So you'd need to know thread type as well (affinity, general queue, spesh, etc.) [22:04] there's a starting thread size and a normal size. main thread starts with normal size, other threads start with smaller size and the first time they are in a gc run they use the full size [22:04] Oh interesting. [22:05] 3:#define MVM_NURSERY_SIZE 4194304 [22:05] 8: * does not grow. If MVM_NURSERY_SIZE is smaller than this value (as is [22:05] 10:#define MVM_NURSERY_THREAD_START 131072 [22:05] But is there any detection of GC thrash that would cause the "normal size" to grow at all? [22:05] Ah, I see the "does not grow" bit, hmmm. [22:06] oh [22:06] i was wrong [22:06] the size doubles if the thread was the one to initiate gc [22:06] 128 kB or 4 MB, hmmm [22:06] Oh! Can that repeat indefinitely? [22:06] no, only up to 4 MB [22:07] Ah, I get it. 4 MB for first thread, 128 kB for additional threads, which can double up to 5 times and then stops when it hits the 4 MB cap. [22:08] that's it [22:09] Why is MVM_NURSERY_SIZE a #define and not a tuneable? Just NYI? [22:09] i believe 4 MB was chosen to be the size of typical L3 caches [22:10] Oh that's interesting. (And I think no longer accurate, since I was just reading that Apple's ARM chips have a crapton of LLC.) [22:10] right, they just put a whole boatload of fast RAM extremely close to their CPI [22:10] CPU* [22:10] OSLT [22:29] <[Coke]> do we have a list of current failures/issues? t/02-rakudo/18-pseudostash.t on mac failed 3/3 [22:30] i'm not aware of such a list [22:41] *** evalable6 left [22:41] *** linkable6 left [23:26] there's a rakudo issue for flappers [23:27] heh, my ryzen 3 3700x has 2x16mb L3 cache [23:30] *** squashable6 left [23:31] *** squashable6 joined