Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-10-07

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

All times shown according to UTC.

Time Nick Message
00:25 travis-ci joined #moarvm
00:25 travis-ci MoarVM build passed. Tobias Leich 'Merge pull request #421 from niner/master
00:25 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/165637599 https://github.com/MoarVM/MoarVM/compare/542b8995ce31...c8d33aebbf4c
00:25 travis-ci left #moarvm
00:46 travis-ci joined #moarvm
00:46 travis-ci MoarVM build passed. Tobias Leich 'use better throw away type for void nativecalls
00:46 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/165639593 https://github.com/MoarVM/MoarVM/compare/c8d33aebbf4c...0bdbd6e04adf
00:46 travis-ci left #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
05:36 domidumont joined #moarvm
05:41 domidumont joined #moarvm
06:02 nebuchadnezzar domidumont: hello, I updated the feature/switch-to-libffi branch, if you could review it
06:13 domidumont joined #moarvm
06:16 zakharyas joined #moarvm
06:19 domidumont joined #moarvm
06:21 nine timotimo: happy to be able to help :)
06:31 geekosaur joined #moarvm
07:21 brrt joined #moarvm
11:30 brrt left #moarvm
11:57 pyrimidine joined #moarvm
12:09 nebuchadnezzar With FROGGS fix for #418, we manage to build MoarVM against libffi but rakudo fails with Floating point exception on armhf: https://lists.alioth.debian.org/pipermail/pkg-rakudo-devel/2016-October/000980.html, any idea?
12:17 geekosaur long division by zero in is_full_collection
12:18 timotimo oh, interesting
12:19 nine I guess we should change src/gc/orchestrate.c:284 to if (uv_resident_set_memory(&rss) < 0 || rss == 0)
12:20 nine Maybe the Linux kernel just doesn't give you an RSS size on all architectuers
12:20 MasterDuke_ joined #moarvm
12:22 timotimo i didn't know we inspect the rss there, interesting
12:25 MasterDuke_ since you guys seem to be on a roll with MoarVM fixes, can i interest you in a segfault that's currently causing lots of problems for the whateverable bots and already has some valgrind and ASAN report? https://rt.perl.org//Public/Bug/Display.html?id=129781
12:29 timotimo hm. i wonder if string_flatten is simply not threadsafe and called by multiple threads on the same string at the same time
12:32 nine This kinda rings a bell
12:32 timotimo i mean ... i don't think string_flatten has any concurrency safety built in
12:33 timotimo but why would multiple threads be running a regex or something on the same string object at the same time?
12:33 timotimo (regex matching is one of the things that causes string flattening)
12:34 nine I knew this sounded familiar: http://irclog.perlgeek.de/perl6/2016-08-26#i_13093882
12:34 MasterDuke_ string_flatten only seems to show up in the ASAN output, but this pattern is in most of the valgrind outputs
12:34 MasterDuke_ ==30661==    by 0x507B366: uv_mutex_destroy (thread.c:114)
12:35 MasterDuke_ ==30661==    by 0x4FFEDA1: gc_free (ConcBlockingQueue.c:72)
12:35 MasterDuke_ ==30661==    by 0x4FCC0C4: MVM_gc_collect_free_nursery_uncopied (collect.c:580)
12:35 timotimo right, that one's also weird
12:35 MasterDuke_ ==30661==    by 0x4FC8B46: MVM_gc_global_destruction (orchestrate.c:511)
12:35 MasterDuke_ ==30661==    by 0x505CDF1: MVM_vm_destroy_instance (moar.c:391)
12:35 timotimo not sure why we would be trying to destroy the mutex multiple times
12:37 MasterDuke_ i get less bad behavior if i explicity use Lock.protect, but it doesn't seem to fix it entirely
12:38 timotimo oh, also if the error happens in MVM_vm_destroy_instance, then we're shutting down already anyway
12:38 diakopter joined #moarvm
12:38 MasterDuke_ i mention in the bug report that the error goes away if i do an exit, instead of just falling out
12:39 timotimo that's also strange. those should be kind of the same :)
12:39 timotimo "to my knowledge" anyway
12:40 timotimo but that error is probably not going to happen if you don't do --full-cleanup for moarvm, right?
12:40 MasterDuke_ but i think we see it with the bots because we run() perl6 executables
12:41 MasterDuke_ ^^^ expansion to my previous comment, not reply to yours
12:41 MasterDuke_ we don't usually run with --full-cleanup
12:42 timotimo OK, fair enough
13:26 dalek MoarVM: 03352f8 | niner++ | src/gc/orchestrate.c:
13:26 dalek MoarVM: Gracefully handle a 0 RSS reported by the Linux kernel
13:26 dalek MoarVM:
13:26 dalek MoarVM: May fix a Floating point exception on armhf in case the reason is that
13:26 dalek MoarVM: the Linux kernel just reports a 0 for RSS there.
13:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/03352f8784
13:26 dalek MoarVM: 67dbb75 | lizmat++ | src/gc/orchestrate.c:
13:26 dalek MoarVM: Merge pull request #422 from niner/master
13:26 dalek MoarVM:
13:26 dalek MoarVM: Gracefully handle a 0 RSS reported by the Linux kernel
13:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/67dbb7517e
13:26 nine nebuchadnezzar: can you please re-test with this version ^^^?
13:58 nebuchadnezzar nine: thanks a lot. domidumont could you try the build?
14:14 jnthn nine: Send you a MoarVM commit bit invite :)
14:14 jnthn *Sent
14:17 nine \o/
14:22 nine Wow...I think through valgrinding Inline::Perl5 I've found an actual bug in perl
14:22 timotimo oh, neat!
14:22 hoelzro joined #moarvm
14:41 nine The remaining Inline::Perl5 valgrind error looks a bit like a MoarVM issue to me: https://gist.github.com/niner/582e3dc1034eb4cee802d85d00e7a0dd
14:46 jnthn Odd one.
14:48 jnthn Maybe reposses wants to memset after gc_free
14:48 nine Sounds a bit like the "re-allocate all the bits inside" the comment promises never happens because we get by with being lazy in that case?
14:48 jnthn That may well be the case, yeah
14:49 jnthn Though I didn't think we were
14:49 jnthn (Being lazy about repossessed things)
14:50 jnthn If the array it's replaced with were to be empty, though, we might never allocate storage again thinking it's not needed
14:50 jnthn And thus leave the dangling pointer
14:50 jnthn It's probably more robust/performant to fix it in serialization.c rather than in the REPR
14:51 nine I can give it a try
14:51 jnthn nine++
14:55 jnthn bbl
14:55 nine Is the storage spec what I'm looking for trying to find the size of the object's body?
14:57 timotimo MVMObject has a size member in its header
14:57 timotimo it's the header + body size
14:57 FROGGS joined #moarvm
15:04 timotimo i'm just listening to this talk by chandler carruth (works at google, part of the llvm dev team) and one big point he makes is having a "small-size optimized" variant of a vector class (what c++ calls dynamic arrays) is a gigantic win
15:04 timotimo that's kind of what we'd get when we have allocation-site specific pre-sizing of arrays
15:05 timotimo but maybe we also want a little piece of implementation that'd allow us to allocate the dynamic array immediately next to the object as part of the nursery when it initially gets built
15:05 timotimo so we don't reach out to malloc for the first allocation
15:05 timotimo because: hey, maybe a whole lot of lists end up being only ~4 elements big?
15:05 timotimo like an RGB or RGBA tuple for example, or a 2d or 3d vector
15:06 timotimo on the other hand, if you use an actual class for those, you'll get "pre-sizing" for free, as well as having all object body data immediately in the nursery
15:10 timotimo i wonder if we'd be able to figure out at an allocation site that a list we're allocating needs to be exactly as big as another list we already have at that point
15:10 timotimo that'd be kinda neat, but also potentially difficult
15:18 dalek MoarVM: 9a2ab14 | niner++ | src/6model/serialization.c:
15:18 dalek MoarVM: Fix "Invalid free()" in empty repossessed arrays
15:18 dalek MoarVM:
15:18 dalek MoarVM: If the promised deserialization never happens or a deserialized array is empty
15:18 dalek MoarVM: and thus never sees the need to allocate any slots, we could end up free()ing
15:18 dalek MoarVM: an uninitialized pointer.
15:18 dalek MoarVM: Clean the object in serialization.c as gc_free() functions usually are not
15:18 dalek MoarVM: written with the object being re-used in mind.
15:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9a2ab14c60
15:18 nine Spectest clean and removes the valgrind error :)
15:25 timotimo "llvm does everything in the low bits of a pointer"
16:12 jnthn nine: Patch looks reasonable to me
16:17 timotimo jnthn: do we ever want to introduce struct bitfields into moarvm?
16:27 jnthn timotimo: huh, wow, I never knew about those o.
16:27 jnthn o.O
16:27 timotimo this c++ talk i'm watching is saying they should either be the same speed as manually masking and shifting, or noticably faster
16:27 timotimo and they are both in C and C++, but i'm not sure how early it came into C
16:28 jnthn Yeah, would be curious to know
16:28 jnthn Looks from the MSDN like MSVC supports them
16:28 timotimo that'd be nice
16:28 timotimo and they'll likely make the code more readable :)
16:30 jnthn So long as we don't use 'em anywhere we care about exact positioning of the bits :)
16:30 timotimo we're not allowed to form references to individual members, but other than that ... :)
16:31 timotimo i mean, i think we already use a union to figure out if the upper bits of the pointer to mp_int are the flag that it's a smallint ...
16:31 timotimo actually, aren't pointers actually 32bit usually?
16:31 timotimo no, wait
16:31 timotimo it's int that stays 32bit that was the problem
16:32 timotimo maybe we're putting that flag in the lower bits
16:32 timotimo that'd make more sense
16:35 jnthn That's exactly the kind of situation where we'd need to be careful; the ordering and positioning of the bits in the field are compiler/platform dependent.
16:36 domidumont joined #moarvm
16:36 timotimo hm, OK
16:36 timotimo so anything that we make available to rakudo users, for example, that'd be out of the question
16:40 domidumont joined #moarvm
17:22 nebuchadnezzar joined #moarvm
17:31 domidumont nebuchadnezzar: yes. I'm compiling moar on armhf with nine's patch (thanks !)
17:32 nebuchadnezzar domidumont: I'm building a x32 chroot to test if it continue to segfault
17:37 nebuchadnezzar domidumont: it segfault on x32 :-/
18:36 domidumont nebuchadnezzar, nine: rakudo now builds on armhf, but some tests are failing. I'll provide more details tomorrow
18:36 nine domidumont: ok, thanks!
18:56 nwc10 joined #moarvm
18:57 Util joined #moarvm
18:57 japhb joined #moarvm
19:01 geekosaur joined #moarvm
19:08 hoelzro joined #moarvm
19:19 TimToady joined #moarvm
19:19 timotimo joined #moarvm
19:19 ggoebel joined #moarvm
19:19 lizmat joined #moarvm
19:26 zostay joined #moarvm
19:33 btyler joined #moarvm
19:34 diakopter joined #moarvm
19:34 stmuk_ joined #moarvm
19:34 pyrimidine joined #moarvm
19:37 Dunearhp joined #moarvm
19:47 cxreg joined #moarvm
19:47 nine joined #moarvm
19:47 mst joined #moarvm
19:47 sivoais joined #moarvm
19:48 mst joined #moarvm
19:57 _longines joined #moarvm
19:57 mtj_ joined #moarvm
20:07 sivoais joined #moarvm
20:08 konobi joined #moarvm
20:08 avar joined #moarvm
20:08 avar joined #moarvm
20:09 camelia joined #moarvm
20:13 harrow joined #moarvm
20:13 jnthn joined #moarvm
20:18 sivoais joined #moarvm
20:21 ilmari_ joined #moarvm
20:21 BinGOs_ joined #moarvm
20:21 JimmyZ_ joined #moarvm
20:21 psch_ joined #moarvm
20:21 moritz_ joined #moarvm
20:22 arnsholt joined #moarvm
20:22 [Coke] joined #moarvm
20:27 BinGOs joined #moarvm
20:38 _longines joined #moarvm
20:38 nine joined #moarvm
20:38 pyrimidine joined #moarvm
20:39 mtj_ joined #moarvm
20:39 btyler joined #moarvm
20:39 ggoebel joined #moarvm
20:39 TimToady joined #moarvm
20:39 nwc10 joined #moarvm
20:39 avar joined #moarvm
20:39 konobi_ joined #moarvm
20:39 cxreg joined #moarvm
20:39 Dunearhp joined #moarvm
20:39 lizmat joined #moarvm
20:40 jnthn joined #moarvm
20:40 camelia joined #moarvm
20:40 mst joined #moarvm
20:40 stmuk_ joined #moarvm
20:40 japhb joined #moarvm
20:40 geekosaur joined #moarvm
20:47 sivoais joined #moarvm
22:09 geekosaur joined #moarvm

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