github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:01 anatofuz joined
timotimo MVM_args_save_capture always creates an uninterned callsite, even if it'd be a candidate for interning 00:05
but interning takes a mutex for access to the interned callsites data 00:07
00:08 anatofuz left, anatofuz joined
timotimo ohai jnthn, i just saw the comment about having removed the callsite cache that was causing subtle problems, and the possibility to do something smarter in the optimizer later 00:09
i haven't looked into it more yet, but would it make sense to have spesh push the callsites that it sees through try_intern?
00:09 anatofuz left
timotimo if we have a candidate specialized on args, we could cache a callsite, i expect 00:10
00:10 anatofuz joined
timotimo or maybe callsites should have a pointer to a version with the initial parameter stripped, just like the reverse of "with_invocant" 00:13
calling try_intern every time save_capture is called is definitely not a great idea, that much is certain 00:16
contention on that mutex means bad news
though the program got about 3x faster i think
a little less than 3x faster 00:17
OK, this usecapture is actually called inside something that's "certain spesh"ed, i.e. no interned callsite was used to call this function itself 00:28
that could be the root of the problem
ah, yes, the callsite that's used for this call has flattening turned on 00:41
it's followed by three arg_o and an invoke_o, though; i think that means we can justā„¢ use a "3 positional argument" callsite for this? 00:42
i know we've thought about this before, to build callsites for places that use flattening 00:44
benchable6: my $a; $a = $_.starts-with("1").Int for ^1_000_000; 00:52
benchable6 timotimo, No new data found
timotimo benchable6: releases my $a; $a = $_.starts-with("1").Int for ^1_000_000;
benchable6 timotimo, starting to benchmark the 39 given commits
timotimo that may be a bit much
00:57 benchable6 left, benchable6 joined
AlexDaniel it probably is, yea 01:02
doing it with committable first is probably a good idea :)
timotimo benchable6: 6.c my $a; $a = $_.starts-with("1").Int for ^1_000_000; say now - INIT now 01:04
benchable6 timotimo, starting to benchmark the 39 given commits
timotimo those are aliased?
01:08 benchable6 left, benchable6 joined 01:12 anatofuz left 01:13 anatofuz joined, anatofuz left, anatofuz joined
AlexDaniel timotimo: yep 01:26
committable: 6.c my $a; $a = $_.starts-with("1").Int for ^1_000_00; say now - INIT now
committable6 AlexDaniel, gist.github.com/6b02f1b33709b291c3...8d572d404d 01:27
AlexDaniel committable: 6.c my $a; $a = $_.starts-with("1").Int for ^1_000_000; say now - INIT now
timotimo: pretty sure benchable does more than one run on each, which is why it's much slower 01:28
timotimo good point 01:30
committable6 AlexDaniel, gist.github.com/8fb484bd265d43096c...886694a1a0 01:31
AlexDaniel ohā€¦
I see what you're looking for
right? wtf 01:32
bisect: old=2017.03 new=2017.04 6.c my $a; $a = $_.starts-with("1").Int for ^1_000_000; say now - INIT now
bisectable6 AlexDaniel, On both starting points (old=2017.03 new=2017.04) the exit code is 1 and the output is identical as well
AlexDaniel, gist.github.com/d8f1a09e7fc04af284...473d174226
AlexDaniel bisect: old=2017.03 new=2017.04 my $a; $a = $_.starts-with("1").Int for ^1_000_000; say now - INIT now
timotimo i don't think bisect can do that?
AlexDaniel why not
bisectable6 AlexDaniel, Bisecting by exit signal (old=2017.03 new=2017.04). Old exit signal: 0 (None) 01:33
timotimo the difference is chaotic
oh
you're going for the crash
no that was a timeout
AlexDaniel we can also set timeout=3 and do it again
or we can exit 42 if 3 < now - INIT now
timotimo mhm 01:34
well, i'm off to bed for now, tho
bisectable6 AlexDaniel, bisect log: gist.github.com/e33160df3321a54e75...8d7ef325e4
AlexDaniel, (2017-03-18) github.com/rakudo/rakudo/commit/8c...60bdb9f5a1
AlexDaniel good night!
c: 8c88b0cc6^,8c88b0cc6 my $a; $a = $_.starts-with("1").Int for ^1_000_000; say now - INIT now
committable6 AlexDaniel, Ā¦8c88b0cc6^: Ā«1.8792102ā¤Ā» Ā¦8c88b0c: Ā«Ā«timed out after 10 secondsĀ» Ā«exit signal = SIGHUP (1)Ā»Ā» 01:35
AlexDaniel yup
github.com/rakudo/rakudo/issues/3185 01:38
done
c: 2016.05,2016.06 my $a; $a = $_.starts-with("1").Int for ^1_000_000; say now - INIT now
committable6 AlexDaniel, Ā¦2016.05: Ā«0.8382520ā¤Ā» Ā¦2016.06: Ā«1.00037587ā¤Ā»
AlexDaniel c: 2016.05,2016.06 my $a; $a = $_.starts-with("1").Int for ^1_000_000; say now - INIT now
committable6 AlexDaniel, Ā¦2016.05: Ā«0.8197042ā¤Ā» Ā¦2016.06: Ā«1.03086281ā¤Ā»
AlexDaniel c: 2016.05,2016.06 my $a; $a = $_.starts-with("1").Int for ^5_000_000; say now - INIT now 01:39
committable6 AlexDaniel, Ā¦2016.05: Ā«3.946849ā¤Ā» Ā¦2016.06: Ā«4.82430794ā¤Ā»
AlexDaniel c: 2016.05,2016.06 my $a; $a = $_.starts-with("1").Int for ^10_000_000; say now - INIT now
committable6 AlexDaniel, Ā¦2016.05: Ā«7.7233457ā¤Ā» Ā¦2016.06: Ā«9.6222518ā¤Ā»
AlexDaniel bisect: 2016.05,2016.06 my $a; $a = $_.starts-with("1").Int for ^1_150_000; say now - INIT now 01:40
bisectable6 AlexDaniel, Using old=2016.05 new=2016.06 in an attempt to do what you mean
AlexDaniel, Bisecting by output (old=2016.05 new=2016.06) because on both starting points the exit code is 0
AlexDaniel nonono
c: 2016.05,2016.06 my $a; $a = $_.starts-with("1").Int for ^1_150_000; say now - INIT now
committable6 AlexDaniel, Ā¦2016.05: Ā«0.9978324ā¤Ā» Ā¦2016.06: Ā«1.2120359ā¤Ā»
bisectable6 AlexDaniel, bisect log: gist.github.com/d518f07d5ef9e5f1ee...95df69256e
AlexDaniel, (2016-05-21) github.com/rakudo/rakudo/commit/2f...19acbdbeeb
AlexDaniel c: 2016.05,2016.06 my $a; $a = $_.starts-with("1").Int for ^11_500_000; say now - INIT now
committable6 AlexDaniel, Ā¦2016.05: Ā«8.89256761ā¤Ā» Ā¦2016.06: Ā«Ā«timed out after 10 secondsĀ» Ā«exit signal = SIGHUP (1)Ā»Ā» 01:41
AlexDaniel bisect: 2016.05,2016.06 my $a; $a = $_.starts-with("1").Int for ^11_500_000; say now - INIT now
bisectable6 AlexDaniel, Using old=2016.05 new=2016.06 in an attempt to do what you mean
AlexDaniel, Bisecting by exit signal (old=2016.05 new=2016.06). Old exit signal: 0 (None)
AlexDaniel fwiw I'm just having some fun
bisectable6 AlexDaniel, bisect log: gist.github.com/7a309aecb567103719...881f1f387b 01:43
AlexDaniel, There are 10 candidates for the first ā€œnewā€ revision. See the log for more details
AlexDaniel that actually looks about right 01:44
c: 2017.01,2017.02 my $a; $a = $_.starts-with("1").Int for ^10_000_000; say now - INIT now
committable6 AlexDaniel, Ā¦2017.01,2017.02: Ā«Ā«timed out after 10 secondsĀ» Ā«exit signal = SIGHUP (1)Ā»Ā» 01:45
AlexDaniel c: 2017.01,2017.02 my $a; $a = $_.starts-with("1").Int for ^5_000_000; say now - INIT now
committable6 AlexDaniel, Ā¦2017.01: Ā«6.5676648ā¤Ā» Ā¦2017.02: Ā«9.1559536ā¤Ā»
AlexDaniel c: 2017.01,2017.02 my $a; $a = $_.starts-with("1").Int for ^6_500_000; say now - INIT now
committable6 AlexDaniel, Ā¦2017.01: Ā«8.482026ā¤Ā» Ā¦2017.02: Ā«Ā«timed out after 10 secondsĀ» Ā«exit signal = SIGHUP (1)Ā»Ā»
AlexDaniel bisect: 2017.01,2017.02 my $a; $a = $_.starts-with("1").Int for ^6_500_000; say now - INIT now
bisectable6 AlexDaniel, Using old=2017.01 new=2017.02 in an attempt to do what you mean
AlexDaniel, Bisecting by exit signal (old=2017.01 new=2017.02). Old exit signal: 0 (None) 01:46
AlexDaniel, bisect log: gist.github.com/db9762241ef207f311...011235277e 01:47
AlexDaniel, (2017-01-25) github.com/rakudo/rakudo/commit/90...20cebdf88c
AlexDaniel uhh ok I'll move to #whateverable :D 01:48
02:19 anatofuz left 02:20 anatofuz joined 03:09 anatofuz left 03:10 anatofuz joined 03:14 anatofuz left 03:15 anatofuz joined 04:06 anatofuz left 04:08 anatofuz joined 04:25 anatofuz left 04:27 anatofuz joined 04:42 anatofuz left 04:49 leedo joined 04:53 anatofuz joined 04:54 tbrowder joined, mtj joined 05:17 anatofuz left 05:18 anatofuz joined 05:23 anatofuz left 05:30 anatofuz joined 06:31 domidumont joined 06:43 anatofuz left, anatofuz joined 06:46 anatofuz left, anatofuz joined 07:08 anatofuz left 07:09 anatofuz joined 07:12 anatofuz left 07:13 anatofuz joined
nine While prohibiting promotion to the old gen yields quite a few more missing MVMROOTs, the extreme runtimes are a real issue. make test's been running for 2 days now and will take a couple more. Estimate a spectest to take about a month. 07:15
So I'm thinking, maybe there's a compromise. If I replace the NURSERY_SEEN flag with a counter, I can give objects several runs in the nursery and have them promoted later. 07:17
There can only be so many allocations between a pointer taken and it getting dereferenced. 07:18
There seem to be 3 bits unused in MVMCollectableFlags. That'd give me 15 rounds in the nursery till I have to promote. That may even be enough. 07:24
07:24 sena_kun joined 07:51 anatofuz left 07:52 anatofuz joined 07:57 anatofuz left 08:06 anatofuz joined
nine Well this improves perl6 -e '' from 5m39s to 3m2s 08:36
And 15 rounds in the nursery ought to be enough for any bug :) 08:37
MasterDuke heh, that's the sort of improvement that probably shouldn't be tweeted about 08:39
08:45 anatofuz left 08:46 anatofuz joined
AlexDaniel MasterDuke: wrong! ā€œit now runs in 54% of the time it used to!ā€ 08:49
:) 08:50
08:50 anatofuz left 08:58 anatofuz joined
nine Lesson learned: always remove memory protections before free()ing as glibc will want to write its own book keeping data into the memory and not actually return it to the OS 09:33
09:38 brrt joined
brrt \o 09:43
dogbert17: please post notes on how to replicate the issue, or create a GH issue and tag me on it
MasterDuke brrt: btw, have you seen my latest replies to you comments on github.com/MoarVM/MoarVM/pull/1139 ? 09:51
brrt hi MasterDuke 09:53
sorry, hadn't
MasterDuke no hurry 09:54
dogbert17 brrt: I ran t/spec/S32-str/sprintf-b.t with a nursery set to 8k. Also I'm on MoarVM e4a756c6aa.
brrt that's rakudo right?
ok, I can try that out
dogbert17 no, it's moarvm, rakudo is on ef2ee79126696
brrt I know, I mean, that's a rakudo test case :-) 09:55
rather than an NQP one
dogbert17 ah, yes indeed
MasterDuke dogbert17: have you ever seen problems with t/02-rakudo/15-gh_1202.t ? 10:02
dogbert17 I believe so yes 10:06
brrt I'm setting the jit-bisect hounds on it 10:08
well, I agree it breaks and is spesh sensitive 10:12
10:16 anatofuz left, anatofuz joined
nine So, I now keep the last 16 fromspaces with protections against reading and writing. Unfortunately this means that we're spending way more time allocating and zeroing the new tospace (since we don't re-use the old one) 10:19
10:21 anatofuz left
nine But, when I remove the superfluous memset after allocating the new tospace, I can recover most of the cost. The tospace will be overwritten with the kept objects anyway and the remaining part gets its own memset treatment. This is also an optimization that may help on master! 10:22
And when I do not double the size of the tospace but extend it by just a page size instead, I can recover the rest of the cost! 10:23
brrt nine++ 10:29
worse, it is PEA sensitive :-o 10:43
brrt grumbles 10:47
MasterDuke here's a new SEGV 10:51
gist.github.com/MasterDuke17/5d049...fb16807292
that's with stock moar/nqp/rakudo, no gc debug or altered nursery size 10:52
still segvs with jit disabled 10:53
brrt MasterDuke: humor me and try with PEA disabled?
MasterDuke: I'm investigating that atm 10:54
10:54 anatofuz joined
MasterDuke seems to run just fine, i.e., no segv 10:54
brrt yeah, was afraid that it would be 10:55
what about inline disabled?
MasterDuke well, it's looking like disabling inlining also fixes it
so maybe it's some interaction between those two optimizations 10:56
brrt yep 10:57
ok
well, I have a spesh log to study
and sure enough: 10:58
[Annotation: INS Deopt Inline (idx 10 -> pc 154; line 149)]
sp_guardconc r10(2), r10(1), sslot(0), litui32(2)
because the deopt_idx is 2, rather than 154, this is using an idx, but it's not updating post-inlining, I think 10:59
MasterDuke easy fix? 11:03
brrt hardly 11:07
but it is at least somewhat obvious where the problem is
theory: the guard op is wrong because of inlining. It breaks because PEA wants the deopt idx for materialization 11:09
and 11:11
previously, we would've done the 'right' thing, because we'd lookup from the deopt source index 11:12
question remains, why the deopt annotation and the deopt index on the instruction are not in sync
11:14 anatofuz left, anatofuz joined
brrt hmm, that's probably not it though 11:24
11:53 brrt left
timotimo i've been dreading looking into this, but i was trying to get the path to some collectable in some heap snapshot and it had an out-of-range reference :| 12:39
12:52 anatofuz left 12:53 anatofuz joined 12:57 anatofuz left 12:59 lucasb joined
timotimo m: nqp::readuint(my $, 0, nqp::const::BINARY_SIZE_16_BIT +| NativeEndian) 13:03
evalable6 (exit code 1) ===SORRY!=== Error while compiling /tmp/ai_F0Hbn1q
Could nā€¦
timotimo, Full output: gist.github.com/d259a4fe79f4dbd5d9...c0c9dfe7f9
timotimo m: use nqp; nqp::readuint(my $, 0, nqp::const::BINARY_SIZE_16_BIT +| NativeEndian)
evalable6 (signal SIGSEGV)
timotimo ^- maybe not very good :) :) :) 13:04
timotimo puts more nqp in moar-heapanalyzer and sees it go much faster 13:11
well, maybe not "much" faster 13:16
13:25 anatofuz joined 13:58 anatofuz left
timotimo m: use nqp; nqp::atpos_2d_i(my $, 1, 1) 14:06
evalable6 (exit code 1) ===SORRY!===
No registered operation handler for 'atpos_2d_i'
timotimo m: use nqp; nqp::atpos2d_i(my $, 1, 1)
evalable6 (exit code 1) This representation (P6opaque) does not support positional access (for type Scalar)
in block <unit> at /tmp/Or7sr_ttZQ line 1
timotimo ^- that's not the right error text, tho, since it could have a positional delegate
i wonder if positional delegates should also support things like read-uint and such
dogbert17 heh, could have sworn I saw Froggs log on 14:20
timotimo yeah, he did 14:21
dogbert17 col 14:22
cool 14:23
somethings up with my keyboard, hmm 14:27
Geth MoarVM: 177706fe2c | (Timo Paulssen)++ | 3 files
better error message for P6opaque in multidim functions

it used to say "the type does not support positional access", but p6opaque has the "positional delegate" mechanism that lets some types offer positional access. it does not, however, offer multidim access. it might at some point, maybe.		 14:30
MoarVM: 0864cb76fb | (Timo Paulssen)++ | 6 files
don't crash with read-int/write-int on unsupported reprs
14:54 dogbert17 left 15:07 brrt joined
brrt I have a theory for the deopts 15:09
hmmm, I may need to improve my theory a little more 15:15
Geth MoarVM: 3e8652ead8 | (Timo Paulssen)++ | src/spesh/worker.c
add missing root for VMEvent SpeshOverviewEvent

  nine++ found this		 15:21
15:25 zakharyas joined
timotimo brrt: what can i put for the size in a "load" node for 64, 32, 16, 8 bit integers? 15:28
or do i just load a 64bit chunk and clear the lower bits and shift over? :P
brrt hmm?
timotimo (template: sp_get_i64 (load (add $0 $1) $2 int_sz))
brrt should put the size of the field needed
yes, int_sz is right there 15:29
timotimo i would imagine int_sz is wrong here, since that is 32 bits
brrt no
timotimo then it's long_sz :P :P
brrt int_sz isn't sizeof(int)
it is MVM_JIT_INT_SZ
and it's 8 bytes
timotimo OK
brrt (maybe that's wrong, but that's the size of an integer in moar)
timotimo "the size of the field needed" is literally what sizeof gives? i.e. size in bytes rather than bits
brrt yes 15:31
timotimo Can't use string ("$1,") as an ARRAY ref while "strict refs" in use at tools/expr-template-compiler.pl line 269, <STDIN> line 2687.
accidentally put a , in my expr template code
brrt bwhat template are you using?
timotimo got this very unhelpful error :) 15:32
brrt :-)
oops
15:32 dogbert17 joined
dogbert17 it seems I somehow managed to pour some coffee into my keyboard, everything went haywire 15:33
timotimo welp, my sp_get_o is wrong 15:35
or one of the others
something makes it segv 15:36
(template: sp_get_o (load (add $1 $2) ptr_sz)) (template: sp_get_i64 (load (add $1 $2) int_sz)) (template: sp_get_i32 (load (add $1 $2) 4)) (template: sp_get_i16 (load (add $1 $2) 2)) (template: sp_get_i8 (load (add $1 $2) 1)) 15:37
oh, does it want one more deref 15:39
oooh 15:40
of course, get_o has to put vmnull if the thing is null
cool that makes it work 15:42
Geth MoarVM: acfb594996 | (Timo Paulssen)++ | src/jit/core_templates.expr
exprjit: templates for sp_get_i* and sp_get_o
 15:44
15:45 brrt left
dogbert17 runs a spectest with a small nursery 15:46
15:49 brrt joined
dogbert17 brrt: did it turn out to be a nasty problem? 15:53
15:55 anatofuz joined 16:00 brrt left
timotimo hum. i seem to be using "if" wrong 16:01
ah, "got reg wanted flag"
i hope brrt will hit me up when he can help me with my sp_p6oget_bi 16:09
brrt, gist.github.com/timo/f32c6731b37e4...0c1de01077 16:12
oooh 16:13
i dereferenced once too often 16:14
i may make the ^bigint_is_smallint macro return a flagval perhaps
then i wouldn't have to put an extra nz to get a flagval back from the int made by the macro 16:15
16:16 gdonald left
timotimo uh, apparently not possible? 16:17
Geth MoarVM: 21b2b13239 | (Timo Paulssen)++ | src/jit/core_templates.expr
exprjit sp_bind_o
 16:22
MoarVM: 0674a1e694 | (Timo Paulssen)++ | 2 files
exprjit sp_p6oget_bi
16:29 anatofuz left 16:44 Ven`` joined
Geth MoarVM: a4a599e350 | (Stefan Seifert)++ | src/6model/reprs/MVMCode.c
Fix possible access to fromspace in MVM_code_location

Allocating the result may trigger a GC run which could move code which we access later on. Fix by moving initialization of result till after we've accessed code.		 16:49
MoarVM: 9138c69986 | (Stefan Seifert)++ | src/core/frame.c
Fix possible access to fromspace in MVM_frame_move_to_heap

The update_caller frame is read at the previous iteration and could be outdated by the allocation at the start of the loop, before we get to assign into it. Fix by adding update_caller to the MVMROOTs.
MoarVM: 07983e4cbc | (Stefan Seifert)++ | src/strings/ops.c
Fix possible access to fromspace in MVM_string_flip

Allocating the res string may cause the original string to move, outdating the s pointer. Fix by MVMROOTing s while allocating res.
timotimo cool 16:50
17:01 anatofuz joined
MasterDuke probably time for nqp/rakudo bumps 17:24
17:31 domidumont left 17:34 Ven`` left 17:35 anatofuz left, Ven`` joined, Ven`` left
lizmat yeah, feels like 17:46
timotimo i just semi-randomly tried adding an OP(blargblarg): in interp.c and didn't get a compiler error, nor a linker error 18:15
i wonder if we can get that to work
japhb timotimo: Meaning, get it to notice that at compile time? 18:21
timotimo yep
labels that are not used are usually not an error 18:22
right?
japhb Dunno, been too long since I tried that.
timotimo ah dang 18:24
some warnings for switches are disabled when a "default" exists
19:04 Kaiepi left, Kaypie joined 19:18 brrt joined, Ven`` joined
brrt \o 19:19
tellable6 2019-09-15T19:17:33Z #perl6-dev <MasterDuke> brrt some expr jit problem colabti.org/irclogger/irclogger_lo...09-15#l238
brrt dogbert17: I think I have a fix
.tell MasterDuke I'll have a look 19:21
tellable6 brrt, I'll pass your message to MasterDuke
MasterDuke brrt: cool. vrurg over in #perl6-dev says he hasn't been seeing it, but his moarvm is a couple days old, which makes github.com/MoarVM/MoarVM/pull/1176 a little suspect 19:22
brrt I'll find the bug I'm sure 19:25
and maybe not because it might be something I fixed already
MasterDuke nice
brrt well, maybe 19:27
Geth MoarVM: 2ac137c3d8 | (Bart Wiegmans)++ | 4 files
[JIT] Use the new deopt index for synthetic guards

Even though the new guard index points to the same target, it doesn't typically have the same deopt_source address as the original one, as that would've been on a prepargs instruction (or similar).
Using the old index would've given us the right target, but anything referencing the deopt index on the new annotation (in particular, PEA) would miss the reference. So we should really use the correct one.
This fixes the bug in rakudo t/spes/S32-str/sprintf-b.t
19:37 sena_kun left
brrt MasterDuke: can you try after I pushed? 19:41
I'm not getting the problem locally
(but that was after I fixed the bug in the commit above, so, who knows)
MasterDuke brrt: the other sprintf-* tests are fine now, but still getting the same error in t/spec/S32-temporal/DateTime.t 19:42
brrt hmmmpf
I'm not
what's your rakudo version?
MasterDuke also t/spec/S32-list/combinations.t is flopping 19:43
brrt anything else that's special?
MasterDuke HEAD, `This is Rakudo version 2019.07.1-317-g7dede2d37 built on MoarVM version 2019.07.1-211-g2ac137c3d`
nope
the error i'm seeing in t/spec/S32-list/combinations.t is `not ok 33 - &combinations with Iterable first argument match calls with method form# Failed test '&combinations with Iterable first argument match calls with method form'# at t/spec/S32-list/combinations.t line 97# You failed 1 test of 33` 19:44
nine Ever wondered if a certain function may trigger a GC run somewhere down the call tree? Just look it up in run_gc's callers: gist.github.com/niner/7630201d7317...047bb2df5a 19:53
Though it's missing the repr functions 19:54
dogbert17 brrt++ 19:57
19:59 Kaypie left, Kaypie joined
nine Updated it with MVM_repr_alloc_init callers 20:01
dogbert17 I suddenly get quite a few fromspace errors with an 8k nursery 20:02
brrt timotimo++ - adding templates 20:07
and yes, the (flagval (eq ...)) and then (nz) is quite redundant 20:08
nine dogbert17: that's....odd. Most of the latest commits were fixes to those
dogbert17 yeah, check this gist: gist.github.com/dogbert17/2541a1e3...44d3eb7bec 20:09
brrt can just be 'ne'
no good deed goes unpunished nine :-)
dogbert17 perhaps I've made some stupid mistake 20:11
brrt MasterDuke: I ahve it passing locally 20:12
do you have a smaller nursery or anything like that?
nine brrt: yes, 8k 20:13
dogbert17 nine, can you repro or is it just me? 20:14
brrt nine: can you replicate the/an issue with t/spec/S32-temporal/DateTime.t ? 20:16
MasterDuke brrt: nope, everything is stock. fwiw, `gcc (GCC) 9.1.0`, `Linux alexandria 5.2.14-arch2-1-ARCH #1 SMP PREEMPT Thu Sep 12 10:42:38 UTC 2019 x86_64 GNU/Linux`, `AMD Ryzen 7 3700X 8-Core Processor`
nine dogbert17: I get a different backtrace. But it doesn't happen on every run
dogbert17 at least I'm not alone :) 20:17
brrt hmm 20:18
nine But I do get the other one consistently if anything happens. It's in OP(set)
brrt d'oh, I'm not actually on master myself
MasterDuke brrt: same if i use clang
dogbert17 brrt: I can replicate problems with t/spec/S32-temporal/DateTime.t
it doesn't SEGV or panic though 20:19
brrt MasterDuke: then tbh, the deopt problems become a little less suspect
dogbert17 can it be the new exprjit stuff which went in today?
nine 3e8652ead seems to be OK 20:20
brrt Ok, on actual master, I can replicate the problem
awesome
I'm almost certainly going to lay the blame at timotimo's feet though :-P 20:22
nine 21b2b13239bab27a88d5e389798c557db434e224 is the first bad commit exprjit sp_bind_o
brrt is going to look at sp_bind_o then 20:23
dogbert17 and he will blame the cats for walking on his keyboard :)
brrt sp_bind_o actually looks quite alright 20:28
nine is thinking the same
But reverting that commit definitely fixes the test
MasterDuke is this a case for jit-bisect.pl?
brrt yes, and I'm running it 20:29
:-)
last frame 5435 20:35
and.. I think there may be something going on with the BB bisect 20:41
20:47 Kaypie left, Kaypie joined
brrt ok, not finding it right now, jit bisect is not working with me today 20:48
20:51 zakharyas left 20:52 anatofuz joined
brrt MasterDuke17: I'm okay with PR #1139 merging, actually 20:52
nine: my theory is, that sp_bind_o probably unblocks something in the expr JIT that's broken, rather than sp_bind_o itself being broken 20:53
but I'm not going to find that today
MasterDuke brrt: cool. i'll merge it after the next nqp/rakudo bump. i don't want it to go in with all these other changes because all the text changes might throw off future bisecting 20:55
20:58 anatofuz left 20:59 brrt left 21:01 Ven`` left 21:34 anatofuz joined 22:32 anatofuz left, anatofuz joined 22:37 anatofuz left
Geth MoarVM/master: 6 commits pushed by (Daniel Green)++, MasterDuke17++ 22:37
22:45 anatofuz joined 22:46 anatofuz left 22:47 anatofuz joined
japhb Wait, did the sp_bind_o commit get reverted before the MoarVM/nqp bump? Or did we just bump to a known broken MoarVM? 22:57
timotimo sp_bind_o is certainly in master 23:06
+2019.07.1-211-g2ac137c3d
and it's bumped into nqp, too 23:07
japhb Yeah, I think the request to bump and the bisect of the JIT problem crossed streams 23:08
timotimo my apologies for angering the jit gods and not being there to brave the thunderstorm 23:09
japhb Heh 23:10
timotimo make test is clean on my end :|
japhb timotimo: What about t/spec/S32-temporal/DateTime.t 23:11
?
23:14 anatofuz left 23:15 anatofuz joined
timotimo "failed one test out of 20" 23:16
and without my patch it succeeds, because of course it does 23:17
23:19 anatofuz left
timotimo so what, one revert commit on top of moarvm, then more bumps? 23:25
23:28 anatofuz joined 23:34 anatofuz left 23:35 anatofuz joined 23:39 anatofuz left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!