github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 07:17
nine Is it morning already? 07:20
nwc10 round here, it's never not morning 07:21
nine true, true 07:23
jnthn It's very morning... 07:56
nine jnthn: do you backlog the channel usually? 08:04
jnthn nine: Depends which, but this one I tend to, to at least pick off the easy questions I can answer quickly-ish :) 08:09
nine Ok, so no need to repeat the things I deep interesting for our architect in residence 08:10
s/deep/deem/
jnthn I didn't yet get chance to read the article about GCC as JIT, to see which of the LLVM as JIT concerns it manages to avoid 08:13
MasterDuke nwc10: is accidentallyquadratic.tumblr.com/p...einsertion relevant for our new hashes? 10:54
nwc10 good question. *Not* for the NQP-visible hashes, as they have randomisation 10:56
for the rest, not sure. And I *was* aware of that artikel, but had forgotten it
thanks for the reminder
somewhat busy with $stuff currently - hence why even the "good *" has been slacking at times 10:57
MasterDuke what do you mean "rest"? hashes used by moarvm internally? 10:59
nwc10 yes 11:02
MasterDuke ah. good that the nqp-visible ones definitely are safe 11:08
nine Ah, take from the rich (element close to its natural bucket) and give to the poor (the one that's moving further and further away from its natural bucket) 11:23
That link contains an excellent explanation of what Robin Hood hashing is :)
nwc10: is the randomisation different per hash? 11:28
nwc10 yes 11:29
jnthn Wow... twitter.com/rkennke/status/1353726110148800513 15:36
nine On another look, the whole string situation in NativeCall is not that bad. Strings require a little extra handling but most of it is already there. After all strings were the only case even considered so far. 16:46
The CStruct's gc_cleanup function just has to take care of strings as well (it can leave non-inlined CStruct/CUnion/CArray members to their object's gc_cleanup). 16:47
One test case however is still an issue: sub take_and_free_struct_but_not_string(StructWithString $s is transferring-ownership(:except<$!s>)) is native($lib) { !!! }
If the struct is freed by the native function, we don't have a pointer to the encoded string anymore. The only place where that was stored is the CStruct and we must not access it anymore after transferring ownership as it may have been freed already (and is in my test ase) 16:49
MasterDuke is there a possible solution? 16:54
nine In theory CStruct's bind_attribute could create an object with CStr representation for bound strings and store that in the child_objs array instead of the original string. Those contain a pointer to the original MVM string and the encoded one and as mentioned yesterday it actually takes care of freeing the encoded string. 16:59
However it's not a perfect match as its MVMString *orig, not MVMObject *orig, i.e. it expects a VMString, not a HLL string object 17:00
But maybe I can make CStr a little more flexible 17:06
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/01/25/2021-...reporting/ 18:38
cog_ lizmat++ 18:42