14 Apr 2024
nine But that's a quite obvious race condition. I'd honestly be quite surprised if that ever made it into the code and even more if it stayed hidden for so long. 08:40
lizmat I guess deserializing is pretty fast?
I mean, it's done at the VM level with internal knowledge about how the REPR is laid out in memory 08:41
and it's also todo with the number of attributes in a class
NQPClassHOW has 21, which I'd say is above average :-) 08:42
I think also the reason is we don't see more of this, is the code path the REA is taking, is relatively unused because of the use of the Proxy in IO::Handle.nl-i 08:53
n
nine I wonder if this could be due to use of an ordinary MVMuint32 as "working" flag in MVMSerializationReader. When this flag is set to 0 we just get the pointer to the object from the SC. If it's set to 1 we call MVM_serialization_demand_object which will lock the mutex first before checking availability of the object. 08:56
lizmat nods while being rubberducker 09:00
*d 09:01
Geth MoarVM/main: d5dafa9b47 | (Stefan Seifert)++ | 3 files
Use atomic operations for on SerializationReader's working flag

This flag is read from different threads than it is written to. This means that when using a plain integer, a thread could read an outdated value from a CPU cache leading to it believing that no deserialization is running when it actually is. This in turn could cause us to read from half-deserialized objects.
  lizmat++ for all the heavy debugging work on this
09:12
nine lizmat: please try with this commit. No guarantees, but it seems obvious enough for me to push straight to main
lizmat ok, will do now :-)
in hindsight, I think this could also explain some flappers in make spectest 09:15
so I'm working on a module for MoarVM bytecode introspection 17:44
some interesting preliminary statistics: the core.c setting has 38033 string on the string heap, 21672 of them are the numeric values 0 .. 21671 17:45
this feels... wasteful ?
or at least potentially subject to re-use, like making them the first 21672 elements in the string heap, so that it could be used for int -> str conversion ? 17:51
jdv nine: how does a stale cpu cache get read in that case? 18:31
nine jdv: one thread writes to that flag (or counter actually), another thread reads from it. If the other thread's CPU already has that memory location in a loaded cache line, there's no reason for it to load it from main memory. After all, that's what the cache is for. 18:55
jdv: when one wants to use such an integer to communicate between threads, one has to use atomic operations. These tell the compiler that cross-thread communication is wanted and the compiler then issues memory barriers accordingly. 18:56
MasterDuke this is kind of interesting. i'm printing some of numbers in runNFA (e.g., size of fates arrray, number of states, total fates produces) and the numbers start to differ between the moarvm and jvm backends pretty quickly 19:21
as in, the third line shows the moarvm backend producing 1 fate and the jvm backend producing 2. then on the fourth line the moarvm backend produces 1 fate and jvm backend produces 26 19:23
a lot of the lines do have the same values, but i expected much more agreement 19:24
lizmat could that be because the JVM backend doesn't have NFG ? 19:30
I'm thinking specifically re newlines 19:31
MasterDuke could be
but wouldn't that only make a difference if the files had carriage returns + newlines? which the nqp sources don't (i think) 19:35
lizmat if I remember correctly, \n, \r\n and \r are all the same synthetic on MoarVM 19:36
to simplify matching on end-of-lines :-) 19:37
MasterDuke hmm. and ugh 19:39
lizmat raku.land/zef:lizmat/MoarVM::Bytecode :-) 20:18
and that concludes my hacking for today
MasterDuke nice 20:30
interesting. i just realized that github.com/Raku/nqp/blame/main/src...6966-L6983 has been untouched in 11 years (aside from my recent changes), and is not in the moarvm backend... 23:00
but the jvm build (on main, not my WIP branch) dies almost instantly with it removed... 23:02
coleman lizmat++ 23:46
15 Apr 2024
nine lizmat: you may want to take inspiration from gist.github.com/niner/63a718023aba...c1ccd84e32 06:42
lizmat nine: thanks, will take that inspiration :-) 09:06
also reminded me of the fact that module precomp files don't start with the MoarVM header :-) 09:07
MasterDuke: much of the code I've been going through the past months, had not been touched for 10+ years 09:08
so welcome to the club :-)
and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/04/15/2024-...y-concise/ 14:26