Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-12-20

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:57 ilbot3 joined #moarvm
02:57 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
06:27 geospeck joined #moarvm
07:33 domidumont joined #moarvm
07:40 domidumont joined #moarvm
09:04 domidumont1 joined #moarvm
09:42 domidumont joined #moarvm
09:44 domidumont2 joined #moarvm
10:33 domidumont joined #moarvm
12:44 squashable6 joined #moarvm
12:44 reportable6 joined #moarvm
12:44 greppable6 joined #moarvm
12:44 unicodable6 joined #moarvm
12:44 benchable6 joined #moarvm
12:56 domidumont joined #moarvm
13:53 brrt joined #moarvm
14:34 domidumont1 joined #moarvm
14:48 geospeck joined #moarvm
14:49 samcv joined #moarvm
16:05 brrt joined #moarvm
16:06 brrt good * #moarvm
16:08 lizmat brrt o/
16:09 brrt \o lizmat
16:09 AlexDaniel` O√
16:40 nwc10 good UGT, brrt
16:41 samcv going to release MoarVM after checking things with NFG_CHECK on
16:42 brrt \o/
16:45 lizmat samcv++
16:50 AlexDaniel` Sounds great!
16:54 * lizmat notices that nqp::isprime_I is not being JITted
17:08 timotimo that'd be trivial to do, lizmat. where do you see it aborting frames?
17:09 lizmat it doesn't turn green in --profile for something like: say (^Inf).grep(*.is-prime).skip(999).head
17:10 timotimo the question is: is it inlined anywhere?
17:11 lizmat in JIT log I see: BAIL: op <isprime_I>
17:12 lizmat dinner&
17:19 timotimo the jit log no longer outputs "entering inline", something must have broken that
17:19 timotimo it only shows "leaving inline"
17:24 zakharyas joined #moarvm
18:09 coverable6 joined #moarvm
18:09 nativecallable6 joined #moarvm
18:44 domidumont joined #moarvm
18:47 Geth ¦ MoarVM: 80976d759a | (Samantha McVey)++ | VERSION
18:47 Geth ¦ MoarVM: Update VERSION file to 2017.12
18:47 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/80976d759a
18:47 Geth ¦ MoarVM: a184d77019 | (Samantha McVey)++ | 2 files
18:47 Geth ¦ MoarVM: Minor ChangeLog and release_guide.md fix
18:47 Geth ¦ MoarVM:
18:47 Geth ¦ MoarVM: Don't repeat "New in 2017.12" twice and make it more clear what the link
18:47 Geth ¦ MoarVM: at the top of the changelog is for.
18:47 Geth ¦ MoarVM:
18:47 Geth ¦ MoarVM: For the release guide, Numbering changed but a step refering to a changed number had not yet
18:47 Geth ¦ MoarVM: been changed, it has been updated now.
18:48 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a184d77019
19:23 timotimo i think we should throw out the second change in the miscellaneous section
19:27 timotimo and the lengthy explanation for why the ucd2c changes are good seems out of place for the changelog
19:28 timotimo and the jit-bisect SPESH_LIMIT change is in two sections in a row :)
19:28 timotimo oh, the release already happened
19:30 lizmat yeah, water under the bridge  :-)
19:31 samcv timotimo: well it can be changed after the fact it's just not in the main release tar.gz
19:31 samcv so feel free to change it
19:31 timotimo right
20:22 geospeck joined #moarvm
20:26 bart_ joined #moarvm
20:27 bart_ good *
20:33 timotimo hey bart, what happened to your name?
20:33 bart_ good question
20:33 bart_ polari chat client isn't respecting my preference clearly
20:40 brrt a memory leak in syncfile?
20:40 AlexDaniel joined #moarvm
20:42 brrt that is weird
20:55 quotable6 joined #moarvm
20:55 brrt joined #moarvm
20:57 committable6 joined #moarvm
20:58 bloatable6 joined #moarvm
20:58 evalable6 joined #moarvm
20:58 bisectable6 joined #moarvm
20:58 releasable6 joined #moarvm
20:58 statisfiable6 joined #moarvm
21:23 brrt we can't run with --full-cleanup at all since that aborts because we try to destroy a lock
21:24 brrt because, gc tries to cleanup the spesh queue object
21:25 brrt and it cant' because it is presumably still locked
21:32 jnthn Can't in any Perl 6 program that ever triggers use of the thread pool for the same reason: a blocking queue implies a lock is held while the condvar waits for the queue not empty signal.
21:32 yoleaux 16 Dec 2017 17:27Z <brrt> jnthn: what is our current policy with regards to process cleanup, because i think we leak memory if we shutdown moarvm before the spesh worker is done, and that angers ASAN
21:32 yoleaux 04:52Z <Zoffix> jnthn: Made a change to 6.d &await that's kinda gross. If you wanted to review: https://github.com/rakudo/rakudo/commit/c51f1796e6
21:33 brrt uhuh
21:33 brrt welcome back jnthn :-)
21:34 brrt so, one thing that i've done, not in C but in python, iirc, is to put a NULL value on the queue when cleaning up, and use that as a signal
21:34 brrt or, alternatively, a constant MVM_QUEUE_CLOSE
21:34 jnthn .tell Zoffix I don't think await should be doing any flattening or descent beyond what *@awaitables does when slurping
21:34 yoleaux jnthn: I'll pass your message to Zoffix.
21:34 brrt would you think that could work here?
21:35 jnthn Well, many threads could be waiting on the cond var, though, and queues are just one place this could happen.
21:36 brrt true, but that's not true for the spesh worker
21:37 brrt so even if we can't in general...
21:37 jnthn If we're not looking for a general solution, then just not even trying to destroy a lock that's held would be an option...
21:39 brrt but then, the --full-cleanup doesn't work
21:39 brrt i'm not sure what solution i'm looking for anyway
21:41 jnthn --full-cleanup has never fully worked
21:41 brrt which is ironic
21:42 jnthn And it gets little love because we don't need it for real work
21:43 jnthn It's been useful to get a clearer picture of memory leaks
21:43 jnthn But it's a hard thing to achieve
21:43 brrt the thing is, that attitude makes it impossible to cleanup existing memory leaks using ASAN and similar tools
21:44 jnthn Well, if somebody has the weeks to invest on making it fully work, I'm not going to say no. :-)
21:46 jnthn I suspect some kind of workaround to make it not do the mutex destroy that blows up would probably suffice for now, though
21:46 jnthn In that sure, that'll still show up as a leak
21:46 jnthn But it's a lot less noise than without it
21:47 jnthn If we want to borrow a more general solution, then the JVM has some good inspiration here. It provides a park/unpark mechanism implemented in terms of a single cond-var per thread
21:47 jnthn It then implements all of its locks, conds, etc. *on top* of that park mechanism
21:48 jnthn Thus my predicition of O(weeks): implementing our own locks/condvars would need *very* careful work.
21:49 jnthn Anyway, in that scheme you just signal all threads at shutdown time and get them to exit
21:49 jnthn That deals with *most* things
21:49 jnthn (However, not things stuck in some foreign function call, or blocking I/O)
21:51 brrt dirty hack would be somehow preventing that lock from being cleaned up
21:51 jnthn That's what I suggested above
21:51 jnthn Locks have a "is this lock held" flag
21:51 brrt uhuh
21:51 jnthn So I figure we can use that
21:52 brrt i'm curious about how the JVMs lock/unlock stuff works
21:53 jnthn Yeah, it's probably the right overall direction
21:53 jnthn But...in terms of things that are tricky to implement... :-)
21:56 jnthn (Also, if I don't make as much sense as on a good day, it's 'cus I'm doing the hopefully-nearly-the-end bits of flu...)
21:58 brrt let's hope it is the end bits indeed :-)
21:58 brrt but unfortunately, it makes some sense, yes
21:58 brrt hmm
22:00 jnthn Yeah, it's been a week since I first woke up and thought "urgh, this feels like it's going to be a heavy cold..."
23:12 samcv i have a cold or flu right now ::(

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary