github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke huh. an extra 390m instructions compiling rakudo when moarvm was built with -flto 01:52
according to callgrind
05:38 Util left 05:51 Util joined 06:07 domidumont joined 06:09 Kaiepi left 06:10 Kaiepi joined 06:45 sena_kun joined 07:19 patrickb joined
nwc10 SEGV in libuv during nqp's make install - I can't reproduce this - paste.scsys.co.uk/584367 07:38
er, wait, that was rakduo make install 07:50
I'm very confused. but it was really a SEGV and I really can't reproduce it 07:51
I fear that the problem is that the coffee machine at work isn't working well
08:32 brrt joined
brrt \o 08:32
timotimo o/ 08:33
brrt: how do you suggest i put this into the jit: pass an object body + an offset as an argument to a C function?
brrt you want two arguments? 08:35
timotimo pretty much
brrt you want the body + offset as a pointer, or the offset as an integer 08:36
timotimo one way i've considered was to have a "just take TMP5's contents" and another node that calculates a p6o's object body offset 08:37
(including the real_data pointer)
the body + offset as a pointer
gimme a sec
github.com/MoarVM/MoarVM/blob/mast...que.c#L490 - basically this 08:38
the last argument is what normally has the OBJECT_BODY, but in this particular function it already got the OBJECT_BODY as the void *data pointer
(but also it had to do the p6opaque_real_data thing itself)
wait, i think what i'm actually after is github.com/MoarVM/MoarVM/blob/mast...ue.c#L1357 08:40
hum, is that different to just using getattr_o and then atkey_o?
08:44 zakharyas joined
timotimo now which one did i actually want :| 08:47
if it's actually just getattr (well, p6oget_o really) plus the original thing, that'd go into spesh instead 08:48
so the only difficult part is with the unboxing ops that have to go pick out a pointer from inside, but only use it for the void *data argument, so that has to be in the jit
anyway, please excuse me, i kind of woke up quite recently 08:49
brrt oh, you want a dynamic offset 09:16
I se
*see
I kind of don't want the old style function invocation to be overloaded further
but
meh
timotimo it's not actually dynamic, it's known at jit time 09:18
would the "this argument shall just take TMP5's value" thing be okay?
09:39 brrt left 09:45 domidumont left 10:25 brrt joined 10:51 zakharyas left
brrt timotimo: that seems very, very brittle 11:29
timotimo oh 11:31
should i use stack-relative values instead?
11:54 domidumont joined 11:56 domidumont1 joined 11:59 domidumont left
brrt maybe, but, if it's a constant at JIT time... can't you just laod that constant? 11:59
oh, I think I get the problem now 12:00
you want to inline that calculation in the JIT
timotimo yes
because there's a double offset, more or less
first i have to get the real_data pointer and check if it's to be followed 12:01
then i have to add the jit-time-constant offset onto that
brrt just for my curiosity... why do we *need* the real-data pointer? 12:06
(I kind of think jnthn knwos the answer to that) 12:07
timotimo it's for mixins 12:08
adding attributes is hard if something else has its header right after your data pointer :)
er, your body i mean 12:09
so when an object grows due to mixins, we copy the data away and hide it behind one layer of indirection
12:13 Geth left, Geth joined
brrt oh, right, got it 12:19
hmm, and I guess we can't patch up all possible references 12:20
timotimo we should be able to do better when doing a nursery copy or nursery to gen2 12:24
i don't think we've done this yet
12:43 reportable6 left 12:47 reportable6 joined
brrt Do you mean, maybe act as if the object is concurrently moved to a new location by the GC? 12:50
that's possible... but expensive, too :-D 12:51
timotimo oh, no, i mean whenever the object moves naturally we grow it at the target site and put the "real data" back in place 12:56
brrt well, we should at least do that, I think.. 13:02
timotimo there's also a possibility for spesh here; if we can tell with relative certainty that an object is going to be mixed in very soon after creation, we can already allocate it with the "future" size and have a mixin op that doesn't do the "copy away and use real_data pointer" thing 13:13
also, i think we're currently paying one pointer of memory in every p6opaque object ever?
not sure if we can perhaps put a flag in the header; gotta make sure it won't interfere with inlined objects; P6opaque don't get embedded inside p6opaque, right? and p6opaque doesn't get embedded in anything else? 13:14
brrt I don't think p6opaque's get embedded 13:21
but..... I'd argue that having a forwarding pointer always in p6opaque, is in hindsight premature optimization maybe
timotimo oh, you mean always having the pointer there makes things faster because we don't have to go look somewhere else for a flag? 13:22
brrt no... I mean that we try to fit all objects into a fixed format by default, and then have to fit an overflow pointer for when that won't work 13:32
contrast this with v8 hidden classes; all objects start of as extensible maps, and when v8 speculates that the object structure is really fixed, that's when a fixed format is applied 13:33
in hindsight, I mean, augmenting a class or object is an obvious deoptimization opportunity
hence, the optimized code should not have to consider that case 13:34
I know that when this was designed that way, a runtime optimizer wasn't part of moar yet
timotimo but objects coming in can already have been augmented 13:35
13:36 zakharyas joined
brrt the point is that if you default to an open map structure (as in python, perl5, etc) then that doesn't cost you 13:45
or at least, not extra
currently, even our best optimized code still has to deal with this
timotimo do note that augmenting also changes the st 13:46
brrt yes
timotimo but augmenting is very rare in perl6 compared to js and python 13:48
we're more or less equivalent to python with __slots__ arrays i guess? 13:49
14:00 lucasb joined
brrt i think python with the __slots__ array prohibits augmentation, is the thing 14:02
14:05 brrt left
timotimo anyway, just because we're "still" in optimized code doesn't mean we won't encounter an object that has a valid forwarding pointer in it 14:06
though we do use variants of ops that don't look at the forwarding pointer in code that only just allocated some object 14:07
14:31 domidumont joined 14:33 domidumont1 left 14:46 zakharyas left 14:55 patrickb left 15:18 domidumont left
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2019/05/06/...s-to-riga/ 15:24
16:06 domidumont joined
samcv kawaii, just got some. so should finish up the rest of the things for release in a bit 16:56
kawaii samcv: great, thanks! 16:58
17:00 domidumont left 17:05 robertle joined 17:54 zakharyas joined
samcv kawaii, moarvm should be released in about 30 min 18:41
19:00 lucasb left, brrt joined
brrt \o 19:00
samcv hey brrt 19:01
timotimo o/ 19:03
brrt hey samcv, timotimo 19:05
can we start publicly celebarting that TPF got $ GSoC students this year?
samcv yes! 19:06
brrt \o/
samcv 4!
timotimo great!
brrt Not so bad, hey
samcv last year was zero >_>
timotimo 2 of them are p6, right?
brrt Yes, I think samcv and I are both mentors
tadzik \o/ 19:08
awesome :)
so it's official now?
brrt I think so... official publication date was may 6th, 18:00 UTC, and that hour has passed
samcv So this, is not temporary anymore? github.com/MoarVM/MoarVM/commit/0e94d75a 19:13
or is it still "temporary" as far as mentionable in changelog
timotimo we don't have the proper fix for that yet 19:15
samcv ok. i'll leave the changelog entry as it being temporary
brrt what's the bug that it fixes?
timotimo immediate crashes on bsd
as soon as the jit returns anywhere
brrt (or, what did OpenBSD break that we need to work around) 19:16
oh, I see
lol
timotimo it's protecting against malicious code
you know, the code that the jit spits out
brrt :-D
but, I can help there... 19:17
what if, on OpenBSD, we use a setjmp/longjmp pair
samcv kawaii, is this 2019.05 or 2019.04
kawaii samcv: 2019.05 :)
samcv ook :)
brrt it'd be annoying, but it could probably be made to work 19:18
thing is, with the current method, we can update the return address anywhere in the call stack, and it'll work, and cleanup, too
setjmp/longjmp will screw with that
timotimo we can't properly implement return protection support in the jit?
i don't know how it's implemented
Woodi I read lastly, that W^X disabling helps python and others on OpenBSD 19:21
slides from here: lteo.net/blog/2019/04/27/carolinac...h-openbsd/ 19:24
OB have W^X disabled on /usr/local 19:26
Kaiepi i have W^X disabled where i have perl6 installed but the trace traps still happened 19:37
timotimo can the trace trap be caught by moar and the PC checked for a sensible location inside of jit code? 19:38
like, is it a signal like sigsegv that a handler can sensibly be written for?
19:39 Geth_ left
samcv timotimo, want to look at the changelog and see if there's any issues 19:40
then i'll do the release
timotimo ok, link please?
samcv oh i guess it didn't print it
timotimo yeah, new geths need github hooks to be changed a bit
Kaiepi i'll test it out timotimo
samcv i pushed but there was no channel message 19:41
timotimo, github.com/MoarVM/MoarVM/blob/mast.../ChangeLog
timotimo we can get rid of the very first one, that was an earlier commit being wrong that got fixed later
i wonder if we shouldn't have some kind of convention for commits like that 19:42
many changes were inspired by fuzzing, but only one (or so?) changes actually have "fuzzing:" in front; should we put fuzzing in all of them, or none? 19:43
and i think the "max inline size per HLL" line should be shortened? there's a few very long lines and i'm not terribly fond of those, but that's a question of style/preference that we may want to just have a decision for 19:44
i think the commit about sp_getvt_o and sp_getvc_o could perhaps fit into the spesh section better 19:46
deallocatedsplit ā† typo 19:48
Also call optimize_bb for unspecialized inlines seems duplicated 19:49
Lliberalize typo's an l too many (unless this is spanish? :D)
nine As a packager I say less is more. Most of my time packaging rakudo goes into summarizing changelogs so they fit into the line limit of the Open Build Service 19:50
timotimo i'd probably change the toolchain/macOS one to read "check for mixed toolchain", that's probably easier to understand without following the link
i hope that didn't come across as too negative %) 19:52
the changelog is good, and your work is very much appreciated samcv
samcv <timotimo> i think the commit about sp_getvt_o and sp_getvc_o could perhaps fit into the spesh section better 19:53
so what change do i need to take?
timotimo for that comment, or for all the comments?
samcv just that one for now
timotimo ah. i'd say just cut&paste it from Core: to Spesh: 19:54
samcv ah cool 19:55
timotimo, "being deallocated, split" so typo because it's not in separate words? 19:59
timotimo yeah
but i'd possibly change the whole line to something shorter
"count deallocated objects categorized by life time"? 20:00
samcv and "Improve check for used toolchain on macOS" to "check for mixed toolchain on MacOS" 20:05
timotimo, change which whole line? 20:06
timotimo yeah
brrt "deallocate objects by life choices"
timotimo and yes
pffft :D
samcv also what
hahaha
needs to be more specific
XD
brrt timotimo: how it works, is that when the interpreter would effect a control flow change (throwing an exception, for instance, or a nonlocal return), this is effected in the JIT by updating the return address to the correct code position 20:08
so this quite directly violates a check that tries to ensure that you don't
or, that malicious code can't 20:09
samcv brrt, ok so what do i change to what :)
you mean this + [95094ae2] Count objects being deallocated, split this statistic into "deleted while in nursery and not seen before", "deleted while in nursery, but seen in a previous GC run", and "deleted while in the gen 2". 20:10
ah oops i forgot to combine the two commits
looks like a bug in my changelog updater
gonna have to fix the behavior when i combine commits.
err. or maybe not. not sure.it looks like it but maybe that was the whole title 20:11
brrt samcv: idk, I was kidding :-)
samcv yeah looks like the later
well just tell me what to change it to so i can release :-))
timotimo i don't know what it's like now 20:12
do you have a suggestion for putting "fuzzing" on many, or just the one commit message?
samcv can put it on as many or as few as you think is fine 20:13
Kaiepi <timotimo> like, is it a signal like sigsegv that a handler can sensibly be written for?
you can catch SIGTRAP, yes
samcv i maybe removed it from some since it wasn't needed to understand the message (at least from my opinion at the time)
timotimo well, catch, sure. how do you properly react? if you think the thing was legit, just return, otherwise just kill your own process with the same signal again? 20:14
or exit(1) or whatever
Kaiepi i'm a bit uncomfortable with the idea of trying to determine whether or not what the kernel's doing is justified 20:16
samcv brrt, though seriously what do i change: + [95094ae2] Count objects being deallocated, split this statistic into "deleted while in nursery and not seen before", "deleted while in nursery, but seen in a previous GC run", and "deleted while in the gen 2".
into
then i can release :-) 20:17
timotimo count deallocated objects categorized by life time
any comment on the other things i pointed out?
brrt sleep 20:28
20:28 brrt left 20:38 lucasb joined
samcv kawaii, ok moarvm is released 20:49
kawaii samcv: amazing, thanks! :)
not sure there is time for me to bump nqp and rakudo tonight, but tomorrow could work 20:50
samcv no problem :)
thanks for doing the rakudo side
timotimo samcv: you kept "lliberalize" :D 20:53
21:03 zakharyas left 21:21 sena_kun left 22:40 lucasb 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!