01:48 ilbot3 joined 05:33 domidumont joined 05:52 domidumont joined
dalek arVM/even-moar-jit: 2d9434e | brrt++ | docs/jit/register-allocator.org:
Map out more of the cruft that needs removal
 06:48
06:48 brrt joined 07:48 zakharyas joined
jnthn morning, #moarvm 08:58
moritz \o jnthn 09:07
brrt \p 09:10
timotimo \q 09:11
brrt haha
timotimo that's my pony tail 09:17
brrt then in my case it should be \u
(beard and balding) 09:18
timotimo aaw
brrt would rather not, but can't be helped 09:21
jnthn Hm, I suspect a day or so before the relaese isn't the best time to do the Unicode 9 bump :) 09:23
brrt no… i suspect not 09:24
(the everlasting drum of the release march)
jnthn :) 09:28
It'd probably go fine, I'm just a little risk-averse :)
I suspect I'll do some bug fixes this morning, and then continue doing I/O stuffs this afternoon :) 09:29
brrt ugh, i'd check if the IO-Socket-Async thing was better now, and haven't yet 09:30
konobi oh... did i mention that there's a portable version of libumem available which gives lots of fun insight, debugging, guards and analysis of memory management (as an LD_PRELOAD or shared lib) 09:34
brrt i think you did not 09:35
konobi i found it very useful when working on nodejs and stopping myself from kicking myself in the ass with memory leaks and faulty references/pointers, etc. 09:36
especially with the stack being as dynamic as it is in async code
dalek arVM: ef129c4 | jnthn++ | src/core/threadcontext.c:
Fix missing finalization queue cleanup.

Only a small leak, but it adds to the clutter when looking at valgrind leak check output.		 10:24
10:50 travis-ci joined
travis-ci MoarVM build passed. Jonathan Worthington 'Fix missing finalization queue cleanup. 10:50
travis-ci.org/MoarVM/MoarVM/builds/159836447 github.com/MoarVM/MoarVM/compare/7...129c42cad8
10:50 travis-ci left
brrt wonders if it is time to switch from MVM_JIT_EXPR_ENABLE to MVM_JIT_EXPR_DISABLE 10:51
jnthn Not 2 days before release ;) 10:52
brrt haha
jnthn I guess it passes spectest etc though?
brrt well, even-moar-jit isn't merges
merged yet
jnthn ah
brrt afaik yes
or at least 'as well as master' 10:53
jnthn :)
brrt but that is in part because it does only very, very tiny fragments yet
jnthn I guess on the branch it makes sense...how far are we from that being mergable?
brrt that.. is an excellent question, and i'm glad you asked
my goal for 'mergeable' has been so far: 'will not explode if people without deep internal knowledge add new templates and tiles to it' 10:54
nwc10 brrt: what branch(es) should I test with ASAN?
brrt and includes 'can represent the full range of MoarVM opcodes as templates' and 'can compile all templates that are currently implemented'
nwc10 (not that this is likely to show up all JIT issues. valgrind is more likely to spot others)
brrt nwc10: if you'd test even-moar-jit with MVM_JIT_EXPR_ENABLE=1 set, then I'd be very grateful :-) 10:55
so, with that said…. the missing piece that i'm slowly assembling is a regional register allocator (as in, can deal with IF, CALL and friends) 10:56
the other bit is that I really have to add a few more security pieces to handle all annotations correctly
it is about a weeks worth of work to make it mergeable, but at my current pace, that will take at least another month 10:57
perhaps two
after that, mountains of work left, but less of it 'core' 10:58
jnthn Curious. rt.perl.org/Ticket/Display.html?id=129161 seems to leak because SCs never get kicked out of the weak hash...
(that is, they go unclaimed)
brrt is not sure if he has valgrind on this machine 10:59
brrt has not 11:00
konobi libumem you can run as a preload, so you don't have the emulation overhead of valgrind to contend with 11:02
timotimo kind of like asan, or is umem more than that? 11:04
konobi it's specifically for memory operations 11:05
timotimo oh, so it also handles accesses? regular writes and reads?
how can a preload do that o_O
konobi libc
that's also why libfaketime is so damn handy 11:07
brrt i think it is solaris specific though?
konobi nope, OmniTI made a portable version years ago
brrt cool 11:08
konobi the docs refer to solaris, but it's all actually pretty agnostic platform wise
so with ldpreload you can use a bunch of environment variables to enabled/disable/set/get functionality 11:09
timotimo brrt: "can represent the full range of moarvm opcodes as templates" just means all features that you might need in order to implement each op is there?
brrt yes, and things won't break when doing so 11:10
timotimo OK
you don't blog often enough for me to know what the status towards "can compile all templates that are currently implemented" is :P
nine brrt: so once even-moar-jit is merged, it's mostly a matter of going through profiles and dumps and find opcodes that prevent JITing and implement their support? 11:11
brrt timotimo: that is a very fair point
nine: yes
that is the intention
has been the intention for over a year :-$
timotimo ;) 11:13
konobi so a moarvm opcode is a class with instances, that need functionality... i see a role! mwuahahaha 11:18
timotimo i'm not sure that's accurate
konobi well, representable as one =0) 11:19
timotimo though tbh, many opcodes come with a check "does this object have the right REPR?" and/or "is it initialized?"
konobi rw values
jnthn lunch & 11:20
timotimo we really only have two opcodes that have an rw value
konobi fun for debugging via meta reflection
anywhos... i'm down the MOP rabbit hole again ^_^ 11:21
timotimo OK :)
brrt timotimo: actually rw values are treated as read-only values 11:24
because simpler
or, just as 'read' values 11:25
and they are handled simply by passing the address rather than the value
....
hang on
hmm
no, that doesn't have any ugly repercussions, actually 11:26
konobi is there a pre-existing mop library for C?
nine brrt: looking forward to that. Sounds like fun :)
timotimo well, in the JIT maybe, but code gen and spesh have to handle it differently 11:27
timotimo packs up for driving home
brrt hopes to deliver it soonish
timotimo yay
brrt konobi: i have no idea what you could mean with a MOP library for C :-)
but suggests that soonish for me may be longer that for you
timotimo there's gobject 11:28
that's pretty much a mop library
konobi yup 11:30
a language really only needs 3 features to support a mop... and the 3rd one is usually fudgeable (and sometimes the first two too) 11:31
jnthn returns from lunch and continues leak hunting 12:15
konobi brrt: ah yes... this is what got me working with libumem outside of solaris again... dtrace.org/blogs/ahl/2004/07/13/num...0-libumem/ 12:17
brrt konobi: thanks for the link :-) 12:18
konobi there's practically no overhead (i know of places where it's used in production by default) so it's really handy for running with a harness to catch errors early
jnthn Well dammit, turns out at some point we ended up with EVAL leaking again... :( 12:20
brrt :-( 12:21
i'd venture to suggest that volunteer projects such as MoarVM benefit disproportionally from automated regression tests
konobi www.usenix.org/legacy/event/usenix...nwick.html
brrt but that it is, on the other hand, rather time consuming to set them up 12:22
jnthn wonders how to write a test for this particular case
konobi i actually use bats (TAP for bash) often for more esoteric things
jnthn I didn't last time I fixed it. 12:23
konobi brrt: in the libumem case, it's nice and easy... install on machine, set env vars, consume output after tests are run 12:24
brrt no, it seems like a hard test 12:26
jnthn Seems I fixed it anyway 12:35
A lot faster than last time, because this time I didn't take the diversion of writing a heap profiler :P
moar-ha++
brrt hehe :-) 12:36
that is a cool tool, for sure
jnthn The fix is a one line patch
nwc10 we owe your beer fridge. If only there was some
oh wait
news.perlfoundation.org/2016/09/per...abi-2.html
jnthn Right :)
nwc10 the bit marked "Leave a comment"
konobi brrt: when loaded as preload, just run as normal... you get stats and info in generated artifact files (contents, location, etc. all settable with env vars) 12:40
brrt konobi: I'm fairly sure it is cool. But at this point, I can't really do anything with it, because I'm not working on moarvm atm :-) 12:41
i'll be sure to read the documentation you've sent me
but haven't yet :-)
dalek arVM: 4938b65 | jnthn++ | src/core/bytecode.c:
Mark SC used in bytecode loading as claimed.

Otherwise, it might be considered unclaimed and so go uncollected, thus leading to things like EVAL leaking memory.		 12:42
konobi cool 12:44
15:59 domidumont joined 16:41 Ven_ joined
dalek arVM: 2eedba8 | jnthn++ | src/6model/ (2 files):
Fix a-bit-too-few error in multi cache.

The indexes we store for args are indexes into the args buffer (which includes names) rather than the callsite flags, meaning that they can be up to twice as long. Fixes a bug where we could fail to find some entries when caching callsites with many named args, resulting in the same entries being put into the cache again and again.		 17:52
17:55 Ven_ joined 18:09 Ven_ joined 18:24 FROGGS joined 18:38 Ven_ joined 18:54 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Fix a-bit-too-few error in multi cache. 18:54
travis-ci.org/MoarVM/MoarVM/builds/159951368 github.com/MoarVM/MoarVM/compare/4...edba88d2b0
18:54 travis-ci left
jnthn bah, hung during a git pull 19:33
geekosaur git doesnt handle network glitches well 19:34
(this is actually a problem for me as the upstream NAT router has far too few NAT slots; at times it loses NAT table entries in under 30 seconds...) 19:35
mst geekosaur: ssh proxy via your own box? 19:36
geekosaur I redirect some stuff over a hotspot currently and just retry for anything I don't want to blow extra money for 19:37
20:52 Zoffix 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!