github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:00 lizmat joined 01:21 AlexDaniel joined 05:13 AlexDaniel left 06:36 lizmat left 07:26 domidumont joined 07:43 AlexDaniel joined 07:50 lizmat joined 07:54 robertle left 07:55 robertle joined 08:47 lizmat left 09:07 sena_kun joined
MasterDuke timotimo: you might find this interesting www.phoronix.com/scan.php?page=new...essed-Perf 12:09
12:10 dogbert11 joined 12:13 dogbert17 left, brrt joined 12:16 tobs joined
brrt I think I know the reason for my fastcrash bug 12:17
btw, windows 10 'pro' already makes it fairly easy to have a linux VM
but soon, it'll be even easier
timotimo ah, very nice 12:21
the perf zstd stuff i mean
brrt I haven't read the logs yet 12:22
timotimo a phoronix article 12:23
perf can now write perf.data with zstd compression, and in the future linux might get zstd compression for the perf ringbuffer too
so last night i stumbled upon USDT probes, have you heard of that? 12:24
brrt I don't even know what USDT stands for
timotimo ha
brrt .tell pamplemousse I think the invalid read is the most important thing; because of ASLR you won't always get a segfault 12:25
yoleaux brrt: I'll pass your message to pamplemousse.
timotimo "user-level statically defined tracing"
brrt I think that concept is somewhat familiar...
timotimo the short of it is: the compiled program has a nop in a specific position, and the elf "notes" section has a bunch of metadata that is valid at that particular position
a "provider" as well as a "probe name" and any number of "arguments" that were defined in the source code by way of putting them into a macro 12:26
brrt uhuh
timotimo that's the simplest version of USDT probes that exist
the next step up involves generating a header file from a specification that will also put a semaphore into the program's memory that can be queried by the user program to see if something is currently interested in the trace point
that way you can generate some extra information that's only needed for tracing and would otherwise be overhead 12:27
on a related note, i'd like to have macros that take the name of a struct and do the sizeof operation for you
that way a trace point can be put in that reports the name of the type
also, a hypothetical memory checker could associate struct names with memory positions 12:28
which is perhaps less interesting
brrt I'm not sure I follow... a macro can implement sizeof()? 12:29
timotimo no, it'll put the "sizeof(BLAH)" in for you
but by passing BLAH instead of sizeof(BLAH), the macro can do something with the name of the struct
rather than only the size of the struct
now you might wonder: is this only possible for things the C compiler sees? anything the JIT can do? 12:31
i'm glad you would have asked!
the current approach to dynamically defined tracing points is a fantastic hack
there's a C library that generates a .so file that has the trace point information in it and links that stuff into the running program 12:32
surely there's a tool that understands C and can let me do a full-codebase refactor of MVM_malloc and friends to a macro version? 12:38
welp. custom perl6-based parser it is, then 12:42
i mean it's probably better to have clang parse the thing and use that to find places that are applicable 12:50
ooh the macro can also put a cast in front 12:59
no more (MVMReallyLongTypeNameGoesHere *)MVM_calloc(5, sizeof(MVMReallyLongTypeNameGoesHere))
13:06 brrt left 13:40 brrt joined
timotimo the patch is ready m'lord 13:42
brrt you patched what?
timotimo no, i patched who. what is on second PR 13:43
brrt :-( my patch doesn't work, at any rate
timotimo :o
the fastcrash one?
i kind of missed what that even was :(
brrt the tl;dr is, i'm assigning to each live range, the set of permissible registers (as a bitmap), rather than the exact register-specification that was compiled by the tile compiler 13:44
but that doesn't work
timotimo ah, that
not sure why it's called "fastcrash" except maybe because it crashes fast? 13:45
brrt yes
that's preciesly why
timotimo damn
brrt it will have a more detailed name, when I figure out why it crashes
timotimo with that kind of attitude, it's no wonder it won't work ;)
brrt :-P
timotimo damn it, templates 13:47
#define MVM_CALLOCOBJ(count, type_name) (DTRACE_PROBE2("moarvm", "callocobj", type_name, count), (type_name *)MVM_calloc((count), sizeof(type_name)))
how do i do this right?
type_name is something like the name of a struct, so i'll have to stringify it 13:48
but it doesn't gett hat far
src/core/alloc.h:3:42: error: expected expression before ‘do’
3 | #define MVM_MALLOCOBJ(count, type_name) (DTRACE_PROBE2("moarvm", "mallocobj", type_name, count), (type_name *)MVM_malloc((count) * sizeof(type_name)))
(it points at DTRACE_PROBE2, so i'd assume it's implemented using the do { ... } while (0); trick)
you get much better results when you search for "macro" instead of "template" 13:53
but nothing seems to help? 13:58
brrt gcc -E for to get the macro-expanded source code? 14:01
timotimo how do i get make to spit out the commandline so i can put -E in there? 14:02
brrt ehm... 14:04
14:05 brrt left
timotimo oooh, it's still MVM_STATIC_INLINE, so it expands to many many trace points 14:13
MFW i accidentally put quotation marks in the actual name of the probes and wonder why they don't show up 14:24
OTOH can you blame me with output like this:
b'/home/timo/perl6/install/lib/libmoar.so' b'"moarvm"':b'"mallocobj"'
MFW /usr/include/c++/9/bits/stl_vector.h:1042: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = USDT::Argument; _Alloc = std::allocator<USDT::Argument>; std::vector<_Tp, _Alloc>::reference = USDT::Argument&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed. 14:30
sena_kun C++ <3 14:34
timotimo my mistake the entire time was using "arg0" when they start at 1?! 14:37
14:45 zakharyas joined 15:09 zakharyas left 15:11 zakharyas joined
dogbert11 timotimo: any theories wrt this profiling failure? gist.github.com/dogbert17/daf2b432...8148a074f6 15:13
timotimo gist.github.com/timo/5cff2a0cbcfde...e36a19d11d - fascinating 15:15
dogbert11: huh. good question.
dogbert11 if I turn off MVM_GC_DEBUG there are no panics but the profile itself looks busted, e.g. it claims that there was 1500 GC's 15:19
and the routines tab only contains one entry :(
timotimo mhm 15:23
dogbert11 a mystery 15:26
Kaiepi bastille% valgrind 15:27
zsh: abort valgrind
well fuck
guess i'll ask #openbsd how to get valgrind to run 15:28
timotimo dogbert11: sorry i'm like up to my chin in this trace stuff 15:46
dogbert11 timotimo: no problem :) 16:53
timotimo damn it, some recent change broke things 16:56
and i don't know which changes are the most recent outside the file i just had open and that one's clean 16:57
yay found the probleb 17:01
Geth MoarVM/dtrace_probe_points_for_alloc: 4 commits pushed by (Timo Paulssen)++ 17:03
timotimo if anybody feels the desire to make the build system check if this feature is available and otherwise "do nothing" with the extra data, that would be swell
17:10 evalable6 left 17:11 evalable6 joined 17:25 ggoebel joined 17:58 ggoebel left 18:21 zakharyas left 18:50 domidumont left 19:04 brrt joined 19:10 zakharyas joined
brrt I note my gratitude to whomever has shipped gdb with strawberry perl 19:15
timotimo yo brrt, got ideas for interesting probe points to put into moar? 19:20
brrt I think you mentioned how a probe worked, but not really what it's good for
timotimo oh 19:21
gist.github.com/timo/127c793d7a775...887341d1f2 19:23
check it out
brrt checking
oh, I did a dumb with the register allocator
timotimo maybe i should put the code that generates these along with the results 19:24
there you go 19:26
brrt oh... this is for application-level tracing 19:27
isn't it?
this seems fairly interesting
timotimo yeah 19:28
it has support in the kernel
did you see that it gives the name of structs that are getting malloced? :D 19:29
19:29 brrt left
ugexe i cant clone anything behind this hotel firewall to test, but github.com/rakudo/rakudo/blob/mast...1079-L1087 seems to be broken on HEAD but only on windows 19:30
timotimo ugexe: whaaaaat
ugexe ci.appveyor.com/project/rakudo/rak...pfdx#L4673
they should both be 1999999000000 19:31
timotimo m: say 1998119951808.base(16)
camelia 1D1393ADDC0
19:32 brrt joined
timotimo m: say 1999999000000 - 1998119951808 19:33
camelia 1879048192
timotimo m: my int32 $foo = 2_000_000; say $foo
camelia 2000000
timotimo m: my int32 $accum; for ^2_000_000 { $accum += $_ }; say $accum 19:34
camelia -1455759936
timotimo m: my uint32 $accum; for ^2_000_000 { $accum += $_ }; say $accum 19:35
camelia 2839207360
brrt ... another bug gone... and a new one
timotimo keep your bugs fresh
m: say ([\+] ^2_000_000).grep(* >= 1879048192, :k) 19:38
camelia (61303 61304 61305 61306 61307 61308 61309 61310 61311 61312 61313 61314 61315 61316 61317 61318 61319 61320 61321 61322 61323 61324 61325 61326 61327 61328 61329 61330 61331 61332 61333 61334 61335 61336 61337 61338 61339 61340 61341 61342 61343 6134…
timotimo m: say ([\+] ^2_000_000)[6130]
camelia 18791515
timotimo *shrug*, very strange 19:39
ugexe windows only 19:40
timotimo yeah
but ... why
can you run it with jit disabled?
ugexe i cant clone anything 19:41
timotimo ah, that's the official rakudo appveyor
brrt now, every register is $rbx 19:43
ugexe bumping rakudos moarvm revision one by one until it fails could bitsect it
brrt wonders if bitsect is a typo or just really appropriate 19:45
20:01 zakharyas left
brrt new bug.... 20:03
20:09 brrt left 20:50 brrt joined
brrt success at last 21:03
timotimo \o/ 21:05
i can't seem to get usable stack traces from malloc ...
brrt that's odd 21:11
timotimo when i trace the mallocobj probe i get a whole bunch of good traces, then just "unknown" again 21:12
also, randomly stumbling over some stack traces with lots and lots of add_bb_facts on the stack
fascinating. when i add a "sleep 1" at the end of the perl6 program i get more stack traces 21:20
so perhaps the unwinding of the stack trace happens a bit late, and by that point the executable image is already gone
Geth MoarVM/jit-expr-float: 3aa29c37f7 | (Bart Wiegmans)++ | 3 files
[JIT] Live ranges are given register set

Decode the register spec into a register set during live range determination. Merging register requirements is then an bitset-union-operation. Next step is choosing a live range to spill based on the requesting live range permissible set (to ensure that we release a floating point register for a floating point value, and a GPR register for an integer/pointer value).
21:35 brrt left 21:39 lizmat joined
dogbert11 perhaps this might prove useful github.com/nokia/memory-profiler 23:00

Powered by Cro and the Raku® Programming Language.

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

Thank you!