github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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
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
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
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
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
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...
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
Geth MoarVM/pea: 83a35e95b7 | (Jonathan Worthington)++ | src/spesh/deopt.c
Remove unused variable
 18:17
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
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
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
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!