github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: 55964708fa | (Nicholas Clark)++ | src/strings/utf16.c
`swap_bytes` in utf16.c needs to also swap bytes on big endian platforms.

The way it had been written worked perfectly on little endian platforms, and was actually a no-op on big endian platforms, because it *read* from memory in fixed (little endian) order, but wrote back using bitwise operations, meaning that the read acted as a second byte swap on big endian platforms. This was somewhat LTA.		 07:16
Geth MoarVM: 2a98b8f3aa | (Nicholas Clark)++ | src/6model/reprs/NativeRef.c
MVM_nativeref_{read,write}_lex_i should handle uint8, uint16, uint32

Previously these three (and uint64) all took the `default:` path through the case statement, which meant that they were read/written as 64 bits, eg:
   default:
   return var->i64;
... (13 more lines)		 08:28
nwc10 nine: in CStruct.c at line 520 we have MVMROOT(tc, root, { ... 15:48
within that block, we have at line 519 MVMROOT2(tc, typeobj, root, {
does that make sense?
nine no 15:52
nwc10 :-)
OK, thanks. I assume that that's a cumlative error from refactorign
oh, probably commit b7151da7d7016c0713bc1da3cb1760ea9c302aeb 15:54
linkable6 (2019-09-11) github.com/MoarVM/MoarVM/commit/b7151da7d7 Fix possible memory corruption in CStruct's and CPPStruct's get_attribute
Geth MoarVM: 608b90eb19 | (Nicholas Clark)++ | src/6model/reprs/CStruct.c
No need to MVMROOT `root` twice in `get_attribute`.

This inefficiency was introduced 6 weeks ago as a side effect of commit b7151da7d7016c07:
   Fix possible memory corruption in CStruct's and CPPStruct's get_attribute
   An untimely GC run may move *root before we get to assign the newly created
... (24 more lines)		 18:13
nine Is it me or are MVM_serialization_demand_object and MVM_serialization_demand_stable actually racey? Both create stubs first and add them to the SC's root_objects or root_stables respectively and then enter the work_loop to load the actual data. A different thread may come along, request the same object or stable and get one of these stubs 18:16
Oh, it is me. We're protected against that by the sr->working flag that gets set before the stub is created and only cleared after the work loop is finished. So MVM_sc_get_object will enter MVM_serialization_demand_object (and try to acquire the lock) instead of fetching something from root_objects directly 18:18

Powered by Cro and the Raku® Programming Language.

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

Thank you!