|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:59
undersightable6 left,
undersightable6 joined,
benchable6 left,
reportable6 left,
coverable6 left,
reportable6 joined,
benchable6 joined
01:00
p6bannerbot sets mode: +v undersightable6,
p6bannerbot sets mode: +v reportable6,
p6bannerbot sets mode: +v benchable6
02:01
coverable6 joined
02:02
p6bannerbot sets mode: +v coverable6
02:15
AlexDani` joined
02:16
p6bannerbot sets mode: +v AlexDani`
02:19
AlexDaniel left
02:27
AlexDani` is now known as AlexDaniel
02:35
Kaiepi left,
squashable6 left
02:36
Kaiepi joined
02:37
p6bannerbot sets mode: +v Kaiepi
02:40
btyler_ joined,
AlexDani` joined,
p6bannerbot sets mode: +v btyler_
02:41
p6bannerbot sets mode: +v AlexDani`
02:42
masak_ joined
02:43
p6bannerbot sets mode: +v masak_
02:44
samcv_ joined,
p6bannerbot sets mode: +v samcv_
02:45
dogbert11 joined
02:46
p6bannerbot sets mode: +v dogbert11,
AlexDaniel left,
reportable6 left,
benchable6 left,
undersightable6 left,
bisectable6 left,
evalable6 left,
dogbert17 left,
quotable6 left,
committable6 left,
masak left,
samcv left,
btyler left
02:49
MasterDuke joined,
p6bannerbot sets mode: +v MasterDuke,
MasterDuke left,
MasterDuke joined,
herbert.freenode.net sets mode: +v MasterDuke,
p6bannerbot sets mode: +v MasterDuke
02:54
timotimo joined,
p6bannerbot sets mode: +v timotimo
|
|||
| MasterDuke | timotimo: every once in a while i get distracted by trying to figure out why tools/build/install-core-dist.p6 takes so long. a profile just shows lots of ThreadScheduler stuff and a perf report doesn't seem particularly helpful | 03:03 | |
| i assume it's all the pre-compiling it does. would nine++'s (planned i think) work on precompiling in-process or something like that help? | 03:04 | ||
| timotimo | yeah, it's most probably running subprocesses | ||
| MasterDuke | or is there any better way to figure out what's going on? | ||
| timotimo | there'd have to be something that passes --profile flags to the subprocesses to really see what's going on at all | ||
| MasterDuke | think that'd be easy to hack in temporarliy just to get some profiles of this? | 03:06 | |
| timotimo | i'd at least suggest trying that | ||
| i don't recall if putting a %d in the filename for the profile will cause it to put the PID in the filename there | 03:07 | ||
| that might be important so that it doesn't b0rk | |||
| MasterDuke | ah, good call | ||
|
03:11
evalable6 joined,
p6bannerbot sets mode: +v evalable6
03:16
evalable6 left,
evalable6 joined
03:17
p6bannerbot sets mode: +v evalable6
03:36
bisectable6 joined
03:37
p6bannerbot sets mode: +v bisectable6
03:39
benchable6 joined
03:40
squashable6 joined,
p6bannerbot sets mode: +v benchable6,
committable6 joined
03:41
p6bannerbot sets mode: +v squashable6,
p6bannerbot sets mode: +v committable6
03:42
quotable6 joined,
reportable6 joined
03:43
p6bannerbot sets mode: +v quotable6,
p6bannerbot sets mode: +v reportable6
03:46
undersightable6 joined
03:47
p6bannerbot sets mode: +v undersightable6
03:56
lizmat left
05:39
robertle joined
05:40
p6bannerbot sets mode: +v robertle
06:30
domidumont joined
06:31
p6bannerbot sets mode: +v domidumont
06:39
domidumont left
07:02
domidumont joined
07:03
p6bannerbot sets mode: +v domidumont
08:08
samcv_ is now known as samcv
08:58
lizmat joined,
p6bannerbot sets mode: +v lizmat
09:48
zakharyas joined
09:49
p6bannerbot sets mode: +v zakharyas
10:00
brrt joined
10:01
Kaiepi left,
p6bannerbot sets mode: +v brrt,
Kaiepi joined
10:02
p6bannerbot sets mode: +v Kaiepi
10:56
domidumont left
11:05
brrt left
11:47
brrt joined
11:48
p6bannerbot sets mode: +v brrt
|
|||
| brrt | \o | 11:51 | |
| nwc10 | o/ | 12:05 | |
| timotimo | \o | 12:10 | |
| brrt | everybody's here again :-) | 12:11 | |
| jnthn | .oO( I'm nobody :D ) |
12:15 | |
| brrt | I knew you were lurking here | ||
| okay, I'm also still waiting for nine, lizmat, samcv, MasterDuke, etc. | 12:16 | ||
| lizmat delurks | |||
|
12:56
domidumont joined,
p6bannerbot sets mode: +v domidumont
|
|||
| brrt | I should probably try and get something useful to do. | 13:11 | |
| samcv | hello | 13:18 | |
| brrt | ohai samcv | 13:22 | |
| I've decided I like bitmaps | |||
| Especially for the problem of register allocation | 13:24 | ||
| jnthn | I like bitmaps and I cannot lie...you other hacker's can't deny...that when a hash walks in with a wasteful malloc race and a cache miss in your face | 13:27 | |
| brrt | You'd get stalls | 13:38 | |
| of course, there are dialects that have more registers than 8-byte bitmap can describe | 13:39 | ||
| but not so many | |||
|
13:44
lucasb joined,
p6bannerbot sets mode: +v lucasb
13:47
masak_ is now known as masak
|
|||
| brrt | oh hey, my newly defined register scheme actually compiles... | 13:57 | |
| nwc10 | "ship it!" | 13:58 | |
| brrt | and segfaults | ||
| nwc10 | (thank you for the pause that was just long enough) | ||
| brrt | .oO( If it compiles, it works! So way we all ) |
||
| hmm, I have an idea of what's going wrong though | 14:12 | ||
|
14:19
AlexDani` is now known as AlexDaniel
|
|||
| AlexDaniel | releasable6: status | 14:24 | |
| releasable6 | AlexDaniel, Next release in ā2 days and ā4 hours. 5 blockers. 109 out of 230 commits logged (ā 41 warnings) | ||
| AlexDaniel, Details: gist.github.com/84c8f83acb9ee5888a...8850f4639c | |||
|
14:46
lizmat left
|
|||
| Geth | MoarVM/jit-2op-form: 349bea26b5 | (Bart Wiegmans)++ | 5 files [JIT] Reorganize JIT register definitions - All registers are defined as integers - All sets of registers are bitmaps - Registers are either reserved, available, or spare - A register class is a distinct range of registers (and is implemented as a bitmap mask) I removed the __COMMA__ hack because it wasn't such a terribly great idea anyway. |
14:50 | |
| dogbert11 | jnthn: are you on a blocker hunt? | 14:57 | |
| jnthn | I've just written up notes on one of them | 14:58 | |
| github.com/rakudo/rakudo/issues/2564 I don't really know where to look next for it | |||
| Two of the others look platform specific | 14:59 | ||
| dogbert11 | 2564 is strange, trying to make it fail with asan enabled has so far proved fruitless :( | ||
| jnthn | 2606 looks rather more possible to do something about | 15:01 | |
| dogbert11 | cool, any theories about what's going on there? | 15:02 | |
| jnthn | Not yet, but running it with massif | ||
| dogbert11 | That will perhaps uncover what might be going on | 15:04 | |
| jnthn | Indeed, plugin gone wild | 15:08 | |
| dogbert11 | a wild plugin :) | ||
| jnthn | I'm going to put in an upper limit for the size of the guard set, so bugs like this don't end up running so wild on memory | 15:12 | |
| And then a mode to dump stack traces if it happens | |||
| dogbert11 | so you know what happens but not (yet) why? | 15:15 | |
| Geth | MoarVM: 7fc6be1082 | (Jonathan Worthington)++ | src/spesh/plugin.c Add a limit on spesh plugin guard set size Above a certain size, it's both likely to be a spesh plugin bug, but also likely to not be an optimization at all, so better to just run the plugin each time. Add a mode (off by default) where we dump the stack trace of the location where we were trying to add way too many guards to the set, to help with tracking down such bugs. |
15:23 | |
| jnthn | Yeah. Well, this fix will at least get us to not nom epic amounts of memory | 15:24 | |
| Too many plugin guards added; probable spesh plugin bug | 15:25 | ||
| at SETTING::src/core/control.pm6:62 (./CORE.setting.moarvm:take) | |||
| Curious | |||
| Especially as I can't see what in there would be using a plugin... | 15:27 | ||
| dogbert11 | a mystery then | 15:28 | |
| jnthn | ah, decontrv | ||
|
15:32
AlexDaniel` left
15:33
wictory[m] left
15:37
wictory[m] joined,
p6bannerbot sets mode: +v wictory[m]
15:41
AlexDaniel` joined,
p6bannerbot sets mode: +v AlexDaniel`
|
|||
| dogbert11 | hmm, the valgrind option when building MoarVM seems to have bitrotted unless I'm doing something wrong :( | 15:43 | |
| brrt | decontrv, clearly | 15:44 | |
| jnthn | The plugin seems to be doing the right thing, though. It's just adding one type guard. | ||
| Ah...but we also get an inlining of a spesh plugin too..hmm | 16:00 | ||
| Yeah, it's something to do with that inlined one | 16:06 | ||
| D'oh, think I found it | 16:18 | ||
| brrt eagerly awaits the patch | 16:23 | ||
|
16:24
domidumont left
|
|||
| Geth | MoarVM: 58caebf4f2 | (Jonathan Worthington)++ | src/spesh/plugin.c Use correct static frame in plugin resolution When we inline a speshresolve that needs late-bound lookups, we include the static frame, meaning that we can then inline it. However, part of the spesh plugin handling code just read the static frame of the frame currently on the callstack, rather than using the one it was provided with. If the plugin got new guards, they were resolved in the provided static frame, but the new ones would be stored in the incorrect (currently executing) static frame. This would lead to repeated addition of the same guard to the wrong place, since it would be missed every time. |
16:28 | |
| MoarVM/pea: 35 commits pushed by (Jonathan Worthington)++, (Carl Masak)++ review: github.com/MoarVM/MoarVM/compare/6...a63376373b |
16:37 | ||
| jnthn | Rebase time :) | ||
| Let's see what my next task in here is... | |||
|
16:55
brrt left
|
|||
| Geth | MoarVM/pea: db0c8a7c97 | (Jonathan Worthington)++ | src/spesh/deopt.c Implement deopt materialization of native attrs So that we can materialize scalar-replaced objects during deopt that have native attributes. |
16:56 | |
| jnthn | m: say 0.38 / 0.49 | 17:10 | |
| camelia | 0.77551 | ||
| jnthn | Those numbers are about github.com/japhb/perl6-bench/blob/...mandelbrot | 17:15 | |
| Best time with PEA / without PEA | |||
| dogbert11 | impressive improvement | 17:16 | |
| jnthn | This isn't even especially *good* PEA :) | 17:17 | |
| It's the simplest that could possibly do a few useful things | |||
| dogbert11 | so it will get even better then | ||
|
17:58
zakharyas left
|
|||
| Geth | MoarVM/pea: 83a35e95b7 | (Jonathan Worthington)++ | src/spesh/deopt.c Remove unused variable |
18:17 | |
|
18:19
domidumont joined
18:20
p6bannerbot sets mode: +v domidumont
18:21
brrt joined,
p6bannerbot sets mode: +v brrt
|
|||
| nine | jnthn: I got the compute_allocation_strategy segfault too and there I see the same bogus sc_forward_u that I posted on the ticket: {forwarder = 0xffffffff00000016, sc = {sc_idx = 22, idx = 4294967295}, st = 0xffffffff00000016} | 18:39 | |
| yoleaux | 16 Jan 2019 21:42Z <japhb> nine: Will Inline::Python support python3? Or will you EOL it next year? | ||
| nine | .tell japhb if there's interest, I can certainly port. The changes are not that many | 18:40 | |
| yoleaux | nine: I'll pass your message to japhb. | ||
| nine | jnthn: note however that that's the header of an STable. Does that make a difference? | ||
| jnthn | nine: STables start with MVMCollectable also | 19:09 | |
| So yes, that part is the same | |||
| nine | So 2 very different back traces with segfaults on dereferencing a NULL REPR_data of a CStruct type where sc_forward_u is bogus with exactly the same value: 0xffffffff00000016 | 19:14 | |
| With a nursery of 8K and gc debugging 2 I get a reliable Collectable in fromspace accessed of a CArray with forwarder = 0xffffffff00000016 | 19:31 | ||
| Well with that value in the CArray's st | |||
|
19:32
domidumont left
|
|||
| nine | Another oddity: the faulty object has both the MVM_CF_SECOND_GEN and the MVM_CF_REF_FROM_GEN2 flags set. Don't those flags contradict each other? | 19:34 | |
| jnthn: you did an interesting GC related commit in CUnion. Doesn't the same apply to CStruct? github.com/MoarVM/MoarVM/commit/67...0cb2c38d77 | 19:42 | ||
| japhb | .tell nine Yes, there's interest from me at least. :-) | 20:06 | |
| yoleaux | 18:40Z <nine> japhb: if there's interest, I can certainly port. The changes are not that many | ||
| japhb: I'll pass your message to nine. | |||
| jnthn | nine: ooh, maybe yes... | 20:14 | |
|
20:14
MasterDuke left
|
|||
| jnthn | Though I thought I'd checked some of the others at the time...but it was a whlie ago | 20:14 | |
| nine: I noticed that too, but no: it just means, I think, that the object was born in the nursery, was referenced by a GEN2 object, and then got promoted. Promotion doesn't clear the flag, but the flag is used solely to decide to do early promotion to gen2 | 20:15 | ||
| nine | I'd be highly surprised if the patch wasn't necessary as the CStruct code is virtually identical to the CUnion one | 20:18 | |
| yoleaux | 20:06Z <japhb> nine: Yes, there's interest from me at least. :-) | ||
| jnthn | If that's all it needs, I'd be delighted :) | 20:24 | |
| nine | If only this bug was a little easier to reproduce | 20:36 | |
|
20:37
brrt left
20:44
lucasb left
|
|||
| nine | With the patch I now sometimes get a weird segfault in return_o in this later test: throws-like 'class EmptyCStructTest is repr<CStruct> { };', Exception, message => { m/'no attributes'/ }; | 20:51 | |
|
23:14
lizmat joined,
p6bannerbot sets mode: +v lizmat
23:53
Kaypie joined
23:54
p6bannerbot sets mode: +v Kaypie,
Kaiepi left,
Kaypie left
23:55
Kaiepi joined
23:56
p6bannerbot sets mode: +v Kaiepi
|
|||