00:11 pyrimidine joined 00:58 pyrimidine joined 03:37 pyrimidine joined 04:27 agentzh joined 05:28 pyrimidine joined 05:33 pyrimidine joined 06:34 pyrimidine joined 07:04 agentzh joined
Geth MoarVM/even-moar-jit: 919ee4d8a8 | (Bart Wiegmans)++ | 2 files
Pseudoimplement toposort for ARGLIST

Also change API of prepare_arglist to take both ARGLIST and CALL tiles and panic if they're not adjacent. They are now due to the way the tiling process works, but if they wouldn't be then we'd at least detect it.
07:31
08:21 zakharyas joined
moritz points out that "arglist" is a word in German :-) 08:37
roughly translates to deceitfulness
nwc10 the lies we tell computers... 08:39
that's going to amuse me every time I remmeber it
(thanks)
jnthn And that's exactly why parameters should be validated :P 08:41
08:48 brrt joined
brrt good *, #moarvm 08:48
09:12 agentzh joined
lizmat points out "arglistig" is a Dutch word 09:13
but oddly enough, "arglist" isn't 09:14
brrt well, that surprises me 09:45
i'm not even sure what that means
do you know what it means? 09:56
dogbert17 MasterDuke: for me it fails with the message 'MoarVM panic: Could not spawn thread: errorcode -11'. A quick check with strace gives 'mmap2(NULL, 8392704, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 ENOMEM (Cannot allocate memory)' 10:10
timotimo we don't really have to panic there, do we? 10:12
jnthn If we don't, it might be that we've got a bunch of cleanup to do 10:13
'cus presumably we've prepped stuff for the thread
dogbert17 timotimo, jnthn: if you have had your morning coffee the offending program can be found here: github.com/rbastic/CounterMutexSin...gleton.pl6 10:15
timotimo yeah, uh, 100000 threads is a bit optimistic 10:16
jnthn o.O 10:17
dogbert17 wat, in Erlang that's a piece of cake :)
timotimo but yeah, it should definitely fail earlier when it tries to epoll_create and gets EMFILE
dogbert17 it's RT #123434 btw 10:18
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=123434
timotimo i'll work on a more proper error here 10:19
i can run it with 565 threads 10:20
dogbert17 timotimo: should we continue looking at the coverity stuff later?
timotimo 566 threads and it asplode
dogbert17 I can't create that many :( 10:21
brrt hmm, that exact many? how sensitive is that to MVM_JIT_DISABLE, MVM_SPESH_DISABLE etc?
timotimo disable spesh and it fails already at 526 10:24
brrt okay, so it's not due to speshing
timotimo well, speshing doesn't open many file descriptors, does it? 10:27
timo@schmand /tmp [139]> env MVM_SPESH_DISABLE=1 perl6 CounterMutexSingleton.pl6 --num_threads=526
MoarVM panic: ThreadContext: could not create a new libuv loop!
how's that?
much better than a segfault, no?
next step might be to put in proper cleanup for this case and throwing a catchable exception
Geth MoarVM: c5379702f0 | (Timo Paulssen)++ | src/core/threadcontext.c
panic when new TC can't create an uv_loop

next step might be to put in proper cleanup for this case and throwing a catchable exception. until now it segfaulted.
cf RT #123434
10:28
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=123434
dogbert17 oh, another SEGV gone 10:31
brrt timotimo: why should throwing an adhoc exception not work? 10:32
timotimo *shrug*, it probably should 10:34
jnthn Where are you when you throw it?
timotimo in a BUILD method :P 10:36
called by Thread.start 10:37
brrt uhuh; that's perl code running on some mvm runloop, isn't it?
jnthn But not actually on the started thread yet?
brrt in which case, throwing adhoc should be capturable by the creating thread 10:38
timotimo not on the started thread yet. no
it asplodes while trying to create the thread
jnthn ah, OK, then should work out :)
timotimo i.e. MVM_thread_new is trying to MVM_tc_create, but fails
thing is, we also MVM_thread_new in main.c and when something requests the eventloop to exist
that'll surely asplode a bit more mysteriously whenever someone manages to hit that case in the wild
oh, but 10:39
when we create the thread for the main thread, it'll just grab uv_default_loop 10:40
surely that'll never be null ... :) :)
timo@schmand /tmp> env MVM_SPESH_DISABLE=1 perl6 CounterMutexSingleton.pl6 --num_threads=526 10:45
Could not create a new Thread.
in sub MAIN at CounterMutexSingleton.pl6 line 79
in block <unit> at CounterMutexSingleton.pl6 line 71
dogbert11 nice
jnthn Beats SEGV :) 10:46
timotimo by a large margin
Geth MoarVM: acb20d7f7e | (Timo Paulssen)++ | 3 files
tc_create can now return NULL, throw in thread_new

also panic in moar.c if tc_create returned NULL.
10:48
timotimo interesting. it'll throw the exception way, way, way earlier than it did before 10:52
(with earlier i mean when the num_threads is much lower) 10:53
i'll also want to output the uv error here 11:01
(but how ...) 11:09
i'll actually put the exception throw into tc_create ... 11:10
now how do i sanely figure out if we're in the "the instance hasn't even been set up yet" state ... 11:11
well, the whole instance struct is still nulled at that point, but i'm not sure it's sane to rely on that
oh! in that case instance->main_thread isn't true, so we're fine
cool.
argh :D 11:12
haha
we don't have the tc that's responsible for creating the thread. so throw adhoc with the tc that's in scope is definitely wrong, but i can't just go ahead and guess which one to choose 11:13
oh C, it's so fun to program in you sometimes 11:14
oh! MVM_tc_create isn't MVM_PUBLIC! 11:15
praise the lord
timo@schmand /tmp> perl6 CounterMutexSingleton.pl6 --num_threads=253 11:16
Could not create a new Thread: too many open files
in sub MAIN at CounterMutexSingleton.pl6 line 76
in block <unit> at CounterMutexSingleton.pl6 line 71
Geth MoarVM: b0dc2bf64e | (Timo Paulssen)++ | 4 files
throw from tc_create so we have the error code

also use that error code to give a proper error message. requires tc_create to have the "parent" tc passed, but it's not MVM_PUBLIC, so we can just change the API here.
11:17
dogbert17 you're on a roll :-) 11:19
timotimo nah, all of that should have been a single commit, really ;) 11:20
brrt timotimo++
dogbert17 indeed timotimo++
timotimo replied to the ticket again 11:22
and now AFK for a little bit
someone can go a head and write a test for this :) 11:23
dies_ok ... loop { Thread.new ... } or something like that
dogbert17 what happens if someone has unlimited fd's 11:24
timotimo unlimited, eh?
i want to see the machine that has an unlimited wordsize
dogbert17 :) 11:25
timotimo it looks like num_threads = 253 (the first one it crashes with?) gets up to an fd of 1021
oh, i was wrong
immediately after that it uses pipe2 which allocates 1022 and 1023 11:26
ah, ok, it makes one for the epoll, two for pipe2, and another one for eventfd2
dogbert17 is the function 'uninline' in src/spesh/deopt.c used? There are at least three coverity complaints wrt that function (135422, 135424 and 135436). 12:10
timotimo yes, it is very used 12:11
it's also maximum scary
jnthn Yes, it's used and it's the scariest part of MoarVM IMHO :)
I spotted the complaints, but didn't have the concentration to see how real they are
dogbert17 using several uninitialized vars makes it even scarier or does my eyes deceive me?
timotimo might be best to null out everything you see there :) 12:12
jnthn We can do that for safety of course :)
timotimo or ... look very closely at the trace that allows the uninitialized values to be used
and try to figure out if those traces are actually possible in real-world data
dogbert17 should probably refrain from touching that code then
jnthn It's possible that for <reasons> the traces it detects can't occur in the rewal world.
bbiab 12:13
timotimo you mean the real world. *anything* can occur in the rewal world, however.
the rewal world is a real scary place
good lunch, jnthn :)
dogbert17 the complaints look real enough for my untrained eyes
nwc10 we found this with coverity and the perl 5 regex engine - coverity (legitimately) thought that something might be possible, but the control flow meant that it couldn't happen 12:14
(that doesn't mean that the control flow was clear, obvious or bug free. Although these cases the relevant unit of wetware did have a good audit)
brrt uninline is the stuff of nightmares. it does work though
moritz there are several uses of variables guarded with an if (last_uninlined)
dogbert17 aha, so there is no danger then, perhaps we should follow the old adage 'if it works ...' 12:15
moritz and when last_uninlined is set, those variables are also set
so if coverity complains about last_res_res, last_res_type and last_return_deopt_idx, they are likely false positives 12:16
timotimo oh snap
nwc10 I wouldn't say "no danger". Far from it
but things like ASAN and a lot of abusive tests seem to be useful 12:17
timotimo no danger, william robinson
nwc10 and even more so, fuzzers
timotimo aye
nwc10 American fuzzy lop seems to be particularly cool
moritz designing fuzzing to hit deopt/uninline sounds like fun :-)
dogbert17 perhaps I should move on to another complaint then :)
moritz first have to to create a hot loop for the otpimmization to happen, then break an assumption in made earlier 12:18
timotimo rawr is also very interesting 12:21
no, not rawr, grr.
blog.trailofbits.com/2016/11/02/sh...ast-again/
12:33 pyrimidine joined
brrt mixing-in-at-runtime should be a good way to do it 12:35
maybe somthing like:
role Foo { method Str("foo") }; sub make-foo(Int $i) { if $i > 500 { $i * 3 } else { $i but Foo } }; for ^1000 { make-foo().Str.say; } 12:36
otoh, not sure if that will actually inline anything... 12:37
timotimo don't you mean to reverse the > there? 12:38
so that it starts mixing in stuff late, rather than early?
brrt oh, yeah
you're right
probably should throw in something that would inline 12:39
timotimo right, our operators on native ints seem to do that
but you migh thave to use --optimize=0 to prevent the static optimizer from doing htat
that*
with 90000 threads when stracing i see it do some stuff, then count down from 2000 and calling close on a bunch of fds 12:55
then doing stuff again
then closing stuff
jnthn The static inliner will only do stuff on natively typed subs these days, fwiw 12:56
timotimo right. i suggested to use native int stuff first, then warned to --optimize=0 for that 12:57
i have no idea how far it's come yet, but that script is running without segfault apparently 13:07
this is really gonna take a while 13:13
and i'% about to leave my desktop for the rest of the day
i didn't start the script in a tmux or anything
guess i'll restart it
13:13 agentzh joined 14:04 brrt joined 15:06 brrt joined 15:23 brrt joined 15:34 pyrimidine joined 15:52 pyrimidine joined 16:35 pyrimidine joined 16:40 ggoebel joined 17:26 pyrimidine joined 17:33 pyrimidine joined 17:50 agentzh joined 17:53 pyrimidine joined 17:56 harrow joined
Geth MoarVM: MasterDuke17++ created pull request #540:
Change MVM_string_equal_at_ignore_case to use fc
19:38
19:55 pyrimidine joined 20:37 ggoebel joined 21:56 pyrimidine joined 22:01 pyrimidine joined 22:09 pyrimidine joined 23:22 Geth joined
diakopter .u hurtrealbad 23:40
yoleaux2 No characters found
diakopter :hurtrealbad: 23:42
emoji paste fail