02:25 FROGGS_ joined 04:01 synopsebot6 joined 06:51 synopsebot6 joined 06:55 FROGGS[webchat] joined
FROGGS[webchat] all lights are green for debian! \o/ buildd.debian.org/status/package.php?p=moarvm \o/ buildd.debian.org/status/package.php?p=rakudo \o/ 06:56
moritz \o/ 06:59
07:17 synopsebot6 joined 07:18 domidumont joined 07:23 domidumont joined 07:51 domidumont joined 08:33 zakharyas joined 08:34 FROGGS[webchat] left
jnthn moarning! :) 10:16
nwc10 good *, jnthn 10:17
jnthn Great work on the Debian builds. Nice to see the list of places we run :) 10:18
nwc10 it's not easy being green. (well done) 10:19
domidumont thanks ! :-) 10:29
dalek arVM: 5c65917 | jnthn++ | src/core/nativecall_dyncall.c:
Mark a thread GC-blocked while its in native code.

This means that setting off some long-running C code on one thread will not cause other threads to be unable to perform GC.		 11:27
nwc10 jnthn: is there TFM I should read on what "GH blocked" means?
I'm assuming that when a thread is GC blocked, the others don't wait for it when doing GC 11:28
but who checks what objects owned by it are pointing to?
jnthn When a thread is "GC blocked", if GC happens, another thread will steal its collection work. 11:29
And if the thread unblocks while that is happening, it will wait until the GC is over before continuing onwards. 11:30
nwc10 basically it's sort of an anti-Local-Interpreter-Lock
ie "this MoarVM's state isn't going to be touched"
by default, every thread "locks" its state and only it gets to read it 11:31
jnthn Yes, when you enter blocked state you are promising that you're not going to do stuff like allocate
nwc10 but when going AWOL, a thread releases that lock
jnthn *allocation
nwc10 (and re-acquires it when it returns from elsehwere)
s/read/write/ # earlier
jnthn Right. We already use this technique for things like I/O
And sleep 11:32
nwc10 :-) in that
jnthn So that one thread sleeping or blocking on I/O won't prevent others from being able to collect and get on with stuff
nwc10 with green threads there is only one OS thread, and you release your lock for the duration of doing something "slow"
11:32 domidumont joined
nwc10 here effectively every MoarVM thread then has a green threading-alike on it 11:33
which is held either by the thread itself (when running MoarVM code)
or release, so that someone else can do its housework
released, so that someoen else can hold it as needed, when housework is needed
jnthn Yup 11:34
nwc10 Good.
jnthn That's a good way of seeing it
jnthn just did a build with libffi so he can apply the same change there
nwc10 I'd never thought of this before. The design seems elegant and simple
jnthn Might also be interseting to know that the "am I blocked" flag is also unified with the GC interupt 11:35
github.com/MoarVM/MoarVM/blob/mast...ntext.h#L1 has some documentation around this 11:36
nwc10 thanks - will read after lunch
dalek arVM: f769569 | jnthn++ | src/core/nativecall_libffi.c:
Add nativecall GC block/unblock for libffi too.
 11:46
diakopter timotimo: here's a new fuzzing tool for you: blog.trailofbits.com/2016/11/02/sh...ast-again/ 12:05
12:21 stmuk joined
timotimo jnthn: does that properly unblock a thread when entering a callback? and re-block when returning from a callback into the C code "in between" interpreters? 12:48
i'm not sure how it interacts with the sub-interpreter stuff
ah, i see the handling of callbacks exists 12:51
it's mentioned explicitly in the bump commit
jnthn Yes :) 13:23
14:24 pyrimidine joined
dalek arVM: 2699370 | jnthn++ | src/ (3 files):
Remove dead code.

Firstly, we never modified num_user_threads, so it was always zero. Secondly, the one thing that tried to use it would just hang in a place it should not if we actually did it that way.		 14:40
arVM: 4b9e3a8 | jnthn++ | src/6model/reprs/ReentrantMutex.c:
Fix spello; diakopter++.
diakopter num_user_threads did something someday ago 14:41
hard to recall what
jnthn Yeah 14:42
Fixing global destruction up proper is better done without it anyways 14:43
16:38 synopsebot6 joined 16:39 ggoebel joined
timotimo jnthn: do you have an idea where about ten thousand strings that are all stringified numbers may come from in the string heap? :) 16:40
jnthn cuids 16:44
They used to be much longer :)
timotimo oh, duh 16:47
i wonder if it'd be very hard to turn them into ints now that they are actually just ints anyway?
jnthn Well, it's an interface change 16:48
And bytecode format chance
*change
Well, not if we atoi them I guess :)
timotimo they take about 8 byte each :)
jnthn Uh, more than that surely
timotimo at least the 4-digit ones 16:49
jnthn And MVMString is bigger than 8 bytes before the storage?
*An
timotimo just in the string heap, i mean
i wonder why each string in the string heap is accompanied by four bytes of size info rather than a varint 16:50
jnthn OH, right
nwc10 $because ? 16:51
timotimo if it's just $because and not @because, maybe a work-around can be found ;) 16:52
nwc10 be careful that you don't break the look-ahead code in the object lazy deserialisation if you change stuff
jnthn Since this is not in the serialization blob, the risk of that should be quite low
nwc10 ah OK
superstituous bugs might have figured out quantum tunneling :-) 16:53
timotimo BBIAB, and then maybe i'll turn the string lengths into varints 16:57
17:32 FROGGS joined
FROGGS o/ 17:35
nwc10 \p 17:36
er, ooops
\o
that's better
FROGGS it is :o)
timotimo dinner time \o/ 20:12
FROGGS nebuchadnezzar: this bug is closable now, right? bugs.debian.org/cgi-bin/bugreport....bug=841344 20:41
nwc10 jnthn: paste.scsys.co.uk/538942 -- t/04-nativecall/20-concurrent.t can fail - known? 20:42
ASAN does not have an opinion about this
FROGGS ewww 20:44
I bet this does not happen on windows... 20:45
FROGGS 's experience with concurrency is that it is usually rock solid on windows, less so on linux, and even more less so on bsd 20:46
timotimo MVMuint32 bytes = read_uint32(cur_pos) >> 1; 21:10
cur_pos += 4 + bytes + (bytes & 3 ? 4 - (bytes & 3) : 0);
^- is this something like "string lengths are always multiples of 2" or something?
or something for the fast table somehow? 21:12
jnthn timotimo: I think we pad so that the read of the uint32 is aligned 21:23
nwc10: I couldn't make it fail at all locally 21:24
timotimo ah so with a varint that's no longer an issue
jnthn FROGGS: I actually devloped that test and the stuff it fixes on Windows :)
oops
*on Linux
timotimo i didn't yet see the code that *writes* the string heap :\
jnthn nwc10: Thanks for the example of how it fails though. Travis didn't offer up so much info. 21:25
I'll have to hammer on the test a bit more tomorrow 21:26
timotimo oh! we have a bit of the size be "decode utf8 or not" 21:40
seriously, where is that code hiding o_O 21:51
jnthn To assemble the string heap? 21:55
src/mast/compiler.c or so
timotimo ah, i see it now 21:56
you saved me from madness
jnthn :) 22:08
timotimo i have to fake up MVMSerializationWriters left, right, and center to make all this work >_> 23:25
having the fake SerializationReader on the stack won't work when reading fails, because then it'll try to MVM_free that address when something goes wrong 23:43

Powered by Cro and the Raku® Programming Language.

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

Thank you!