00:33 vendethiel joined 01:45 vendethiel joined 02:29 vendethiel joined 05:04 flaviusb joined
nwc10 OK, 6d3560d84d48f045a3b8f9ae58dd050841aac43b breaks Power64 (which is big endian) 05:37
why
+ ins->operands[2].lit_i16 = MVM_spesh_add_spesh_slot(tc, g, (MVMCollecta
but
+ ins->operands[2] = value;
+ ins->operands[2] = category;
ie, inconsistent use of lit_i16
have to go soon, so don't have time to try to brute force figure this out 05:38
05:58 FROGGS joined
dalek Heuristic branch merge: pushed 23 commits to MoarVM/restricted by FROGGS 06:21
06:34 vendethiel joined 06:53 Ven joined 07:07 Ven joined 08:48 Ven joined 09:05 flaviusb joined 09:07 Ven joined
jnthn ended up with a more correct and simpler fix for the lazy deserialization races, it seems. 09:44
Need to test it some more, but seems promising.
09:50 vendethiel joined
nwc10 good stuff 09:54
I'm very keen to learn if that explains the really weird change of what's called when I play around with the serialisation blob format
meanwhile, the stupid, it burns 09:55
I've tracked down the cause of a very silly bug in the work code
content generation code that has side effects
in some cases
and caching
wrong wrong wrong. must die.
jnthn urgh 09:56
fire it with kill
dalek arVM: 049759b | jnthn++ | src/ (2 files):
Eliminate 100% core use for async things.

Use async wake-ups instead of an idle handler. For this to work out we also need a semaphore to avoid a race in sending the first task to the event loop. GC is also far better handled, using prepare/check handles so another thread can work-steal the event loop thread for GC purposes when it is sleeping awaiting an I/O notification etc.		 09:59
arVM: ffb2574 | jnthn++ | src/6model/serialization.c:
Make demand_[object|stable|code] race-safe.

They now check they didn't lose a race to deserialize, meaning that it is OK for multiple threads to attempt to call them.
arVM: 6ae0ed4 | jnthn++ | src/6model/sc.c:
Prevent reads of partially deserialized objects.

With lazy deserialization we deserialize objects and STables when they are first needed. This worked fine in the single-threaded case, but in a multi-threaded case the mechanism could expose objects and STables that were only partially deserialized, leading to all manner of odd behavior and crashes. This patch fixes the problem by making threads wait if another thread is doing deserialization work on the SC in question.
jnthn That seems to get us the win of not nomming a whole core for the async loop combined with being less crashy :) 10:06
nwc10 and a pony? 10:10
jnthn No pony yet; we still have various concurrency bugs left. 10:15
nwc10: If you have a build with ASAN handy, any chance you could run rt.perl.org/Ticket/Display.html?id=125248 for me under it? 10:16
nwc10 I'm having a rebuild currently for your recent change 10:17
jnthn ah, k
Annoyingly it fails to SEGV under the debugger here 10:21
Ah, but with _NO_DEBUG_HEAP it explodes. Yay. 10:22
Crashes in some arbitrary free, alas. 10:28
Ah, found it 10:39
dalek arVM: 2bc39a6 | jnthn++ | src/strings/normalize.c:
Grow normalization output buffer sufficiently.
 10:41
nwc10 jnthn: unfortuantely 3 tests are deadlocked 10:44
this was the first paste.scsys.co.uk/486554
killing it revealed it to be t/spec/S17-procasync/basic.rakudo.moar
second looks very similar paste.scsys.co.uk/486555 10:45
third t/spec/S17-promise/in.t 10:47
jnthn: ASAN barfage added as a reply on that ticket. 10:49
jnthn nwc10: Great, that ASAN barfage matches what I fixed in 2bc39a6. 10:52
nwc10 oh, my hangs are with local patches. 10:53
I'll go back to origin/master
jnthn nwc10: If it still hangs, please could you try this patch? gist.githubusercontent.com/jnthn/1...tfile1.txt 11:07
nwc10 OK. Still in the setting for the rebuild 11:08
jnthn OK :)
shopping/lunch here; bbiab &
nwc10 jnthn: fewer test failures (I think), t/spec/S17-procasync/basic.rakudo.moar and t/spec/S17-procasync/print.rakudo.moar still hang, in what seesm to be the same way 11:42
had not said, some spectests were failing already
jnthn Very odd 11:55
nwc10: It's confusing in that I don't see how it can get into the state we're seeing 11:57
nwc10: If you've time, you could try gist.github.com/jnthn/4c539e454f5345171120 and paste me the debug output it produces
nwc10 jnthn: paste.scsys.co.uk/486569 12:01
jnthn That's very suspect. 12:06
nwc10 it's very happening :-)
shall I try valgrind?
jnthn Sure. But it means something is very busted, 'cus you should never enter from interupt if soemthing didn't actually try to interrupt... 12:07
You can...I guess there's always a chance we're seeing bogus state
Meanwhile, pasta ready. bbiab
nwc10 non-ASAN build takes a while 12:08
bbiab
12:30 Ven joined 12:53 zakharyas joined
nwc10 valgrind says nothing interesting 12:56
jnthn nwc10: Was that output you pasted me incluidng the patch I sent? 13:17
nwc10 with this: 13:18
- if (tc->gc_status) { \
+ if (tc->gc_status == MVMGCStatus_INTERRUPT) { \
jnthn Wow
ooooh 13:21
Damn, seems I misunderstood something about libuv's check/prepare handlers 13:25
Turns out that it *can* run other handlers between them
OK, fair enough. Deleting code that I thought would help may well fix the thing then :) 13:26
dalek arVM: ae9f21b | jnthn++ | src/ (2 files):
Another approach to eventloop/GC integration.

Turns out there *can* be event handlers run between prepare/check, so the previously taken approach will not work out. Instead, involve the event loop thread in GC by sending it an async wake-up. Hopefully this will fix various hangs.		 13:37
jnthn nwc10: Hopefully this one nails it
nwc10 rebuilding 13:40
only t/spec/S17-scheduler/at.rakudo.moar is hanging 14:04
paste.scsys.co.uk/486593 14:05
jnthn Darn, on Windows too, it seems 14:07
aha 14:16
Right idea, wrong place.
dalek arVM: 07fbd62 | jnthn++ | src/gc/orchestrate.c:
Do wake-up of async event loop inside signal loop.
 14:17
jnthn That unhangs that test here
timotimo <3 14:18
timotimo builds
jnthn Seems I've a "relax in the nice weather and have a pint" invite :) 14:36
File hang/no-hang reports here, and if we're looking good I'll bump MOAR_REVISION etc. when I'm back 14:37
nwc10 t/spec/integration/advent2013-day14.t (Wstat: 256 Tests: 6 Failed: 0) Non-zero exit status: 1 Parse errors: Bad plan. You planned 10 tests but ran 6. 14:41
jnthn++
no hangs, just that one, which is a known flapper
timotimo t/spec/S17-lowlevel/lock.rakudo.moar (Wstat: 139 Tests: 7 Failed: 1) 14:42
Failed test: 7
all else works fine
running it on its own works just fine 14:43
japhb Ooooh ... 15:48
japhb is REALLY looking forward to some concurrency-hardened Moar goodness 15:49
timotimo hopefully it also affects the other stuff like process async 16:01
jnthn timotimo: I think the serialization fix has hopefully nailed much of the remaining instability in the TimToady++ example, at least 17:41
Meanwhile, pint turned into dinner, which was...gulash! :D 17:44
nwc10 jnthn: this makes Power64 happy again, but I don't know why: paste.scsys.co.uk/486642 17:51
tests still fail, but pretty much the same spectests as with MVM_SPESH_DISABLE 17:52
and some async tests that flap
jnthn nwc10: I can easily imagine why
nwc10 OK, so is the whole .lit_i16 a trap? 17:53
or are there times when using the sized members of union isn't correct?
jnthn nwc10: In this csae I think the lit_i16 is the right thing 17:54
If oplist defines it as taking int16 then lit_i16 should be used when setting up or looking at the operands in the spesh graph
So I think the patch is legit 17:55
nwc10 OK. it was more a question of "is it better to have to manually remember that when writing code" vs "could the thing that writes bytes to memory do the necessary truncation and endian fixing"? 17:56
jnthn You should use the correct union member for the opcode you're setting operands for. 18:00
We get away with a bit too much on little endian there.
timotimo jnthn: got a good idea why METAOP_ASSIGN might not be inlined by the optimizer? 18:25
running METAOP_ASSIGN every single time you do a += is a bit wasteful :)
jnthn timotimo: I suspect it's too complex
Produces a closure, and all that
Uh, yes, it is...but we should proably just code-gen those better in the first place 18:26
A bit like we do for .^
(as a desugar)
timotimo (which is why i put that optimization in some time ago and now enhanced it to also work with $foo.bar 18:27
jnthn It shouldn't matter whatn's on the LHS and RHS, the trick is to be sure to assign the evaluation of the LHS to a temporary so as to only do it once 18:29
timotimo right, mouq wrote a patch to fix my latest thingie 18:30
the LHS doesn't matter? would it be all right to just assign anything at all?
because right now i'm making sure the QAST is somewhat restricted
jnthn If it's not assignable and you transform it, it's still not assignable... :) 18:31
timotimo that's fair i suppose :)
i shall simplify in that case 18:32
right now it's just past food time and i'm lightly socialising
jnthn Of cours,e run spectest to be sure
*nod* :0
*:)
timotimo spec tests didn't complain about my previous code 18:33
there was no code to make sure the lhs is only evaluated once :)
19:00 FROGGS joined 21:37 lizmat joined 22:09 FROGGS joined 22:36 FROGGS joined 22:47 vendethiel joined 23:51 nebuchadnezzar joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!