github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM/master: 6 commits pushed by (Nicholas Clark)++ 08:47
Geth MoarVM/hash-stale: ebf22a79ad | (Nicholas Clark)++ | 2 files
Free StrHashTable memory at GC safepoints; track when it is queued to free.

The control structure now has a flag which is set set to 0 when it is allocated. When the hash expands (and needs a new larger allocation) flag is set to 1 in the soon-to-be-freed memory, and the memory is scheduled to be released at the next safe point. This way avoid C-level use-after-free if threads attempt to mutate the same hash concurrently, and hopefully can spot at least some cases and fault them, often enough for bugs to be noticed.
10:17
MoarVM/hash-stale: 01b91fc033 | (Nicholas Clark)++ | 3 files
Check the `stale` sentinel to try to trap concurrent hash accesses.

Previously MoarVM could well SEGV if two user threads access the same hash without locking. Now if it detects concurrent access it will oops instead with a diagnostic. It's not clear to me that we can really recover if we detect this, as concurrent write accesses might have already corrupted the hash structures too far for us to resolve problems.
MoarVM/hash-stale: d181883c05 | (Nicholas Clark)++ | src/core/str_hash_table.c
If two threads "grow" the same hashtable concurrently, we must `oops`.

User threads are responsible for ensuring that they don't access MoarVM hashes concurrently, with mutexes or other concurrency primitives.
If they ignore this there is the potential for VM-level memory corruption and crashes (or worse). Growing hashes is rare, hence we afford the small performance hit of using atomic operations to detect if two threads attempt to reallocate the same hash at the same time, and exit with an informative message if so. (At the point we detect this we can't actually recover as we have a double free.)
Geth MoarVM: nwc10++ created pull request #1492:
Try to trap concurrent hash accesses.
10:18
nwc10 oooh, epic fast fail. I wonder why 10:20
2021-05-16T10:20:00.9382897Z fatal: unable to access 'github.com/MoarVM/MoarVM/': The requested URL returned error: 500 10:22
2021-05-16T10:20:01.0041254Z ##[warning]Git fetch failed with exit code 128, back off 1.507 seconds before retry.
2021-05-16T10:20:02.4582584Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/pull/1492/merge:refs/remotes/pull/1492/merge
2021-05-16T10:20:03.9017049Z remote: Internal Server Error.
2021-05-16T10:20:03.9055517Z remote:
2021-05-16T10:20:03.9117420Z fatal: unable to access 'github.com/MoarVM/MoarVM/': The requested URL returned error: 500
Awesome!
Epic fail.
I shall wait a bit, then hit re-run 10:23
nine The joy of having CI accessing the network and the major reason why I prefer a push to the Open Build Service
nwc10 The left hand of Microsoft is unable to talk to the right hand of Microsoft 10:24
meanwhile, in definate #firstworldproblem, I seem to be about to run out of sherry.
Geth MoarVM: a1cfecd6db | (Stefan Seifert)++ | src/spesh/optimize.c
Fix getting garbage numbers after spesh optimized away smart_intify

Spesh can turn a smart_intify of a num into a guard, sp_get_n and a coercion. However due to a typo instead of coercing the num into an int, we treated the num as an int and "coerced" it again to a num. This turned a 6.0 into 4618441417868443648 causing infix_x to repeat the input string a bit more often than intended, and making us allocate a huge array for the result.
Fixes GH #1466
10:28
nine If only all hard to diagnose bugs where so easy to fix :) 10:29
lizmat feels it is time for another MoarVM bump ? 10:30
nine I wonder if we should re-revert github.com/MoarVM/MoarVM/commit/94...518c590b92 as it's clearly innocent. Or if we should wait for after the release. 10:31
Geth MoarVM: a75a206afb | (Stefan Seifert)++ | src/core/interp.c
Revert "Revert "Always log the type coming out of an nqp::decont""

This reverts commit 9481289950b89dabb553e63d277038518c590b92.
The original commit is clearly innocent. It just unlocked more optimizations which uncovered quite a few spesh bugs. But hiding those won't get them fixed, so let's see what bugs come our way.
10:38
nine lizmat: now I feel like a bump is appropriate :)
lizmat ok will do one 10:39
nine thanks
dogbert11 nine++, absolutely brilliant :) 10:53
lizmat bumped 10:56
dogbert11 I have a few modules cloned, but not installed, on my system. I run their tests from time to time to see if anything strange happens. 11:57
when running 'prove --exec "perl6-m -Ilib"' on [Tux] CSV module I get: Missing or wrong version of dependency 'gen/moar/stage2/NQPHLL.nqp' (from '/home/dogbert/repos/CSV/lib/IO/String.pm6 (IO::String)') 11:58
what could be the reason for this?
wiping the .precomp dir in the modules lib dir will almost certainly fix it 11:59
nine Does RAKUDO_MODULE_DEBUG=1 tell more of the story?
dogbert11 I can check :)
nine: gist.github.com/dogbert17/4708025a...1dfcd56043 12:01
nine Nah...would need closer inspection of those files 12:18
dogbert11 ok, another question, the latest MoarVM fixes made some stuff faster (yay) and a few programs a bit slower. It that to be expected? 12:25
nine commit c8c1b4f2b49564d3b40a22a08e381485ff16d5aa certainly made things slower 12:32
dogbert11 I see slowdown in som scripts, usually it's not that much slower, bu I have one example where the slowdown is ~30 percent which seems to be an outlier 12:34
my spelling is atrocious
execution time before bump was 16 sec and 22 after 12:35
dogbert11 here's the script gist.github.com/dogbert17/36ff5b85...84e46d523a 12:36
MasterDuke nine++ 12:41
Geth MoarVM/MVM_fixed_size_destroy-free-safepoint-overflow-list: 5ba30ed83d | (Nicholas Clark)++ | src/core/fixedsizealloc.c
`MVM_fixed_size_destroy` needs to free the safepoint overflow list.

Otherwise anything oversize that has been queued to free at a safepoint can leak on --full-cleanup.
19:32
MoarVM: nwc10++ created pull request #1493:
`MVM_fixed_size_destroy` needs to free the safepoint overflow list.
Geth MoarVM/hash-stale: ae024a492f | (Nicholas Clark)++ | 2 files
Free StrHashTable memory at GC safepoints; track when it is queued to free.

The control structure now has a flag which is set set to 0 when it is allocated. When the hash expands (and needs a new larger allocation) flag is set to 1 in the soon-to-be-freed memory, and the memory is scheduled to be released at the next safe point. This way avoid C-level use-after-free if threads attempt to mutate the same hash concurrently, and hopefully can spot at least some cases and fault them, often enough for bugs to be noticed.
20:24
MoarVM/hash-stale: d8a16dfd48 | (Nicholas Clark)++ | 3 files
Check the `stale` sentinel to try to trap concurrent hash accesses.

Previously MoarVM could well SEGV if two user threads access the same hash without locking. Now if it detects concurrent access it will oops instead with a diagnostic. It's not clear to me that we can really recover if we detect this, as concurrent write accesses might have already corrupted the hash structures too far for us to resolve problems.
MoarVM/hash-stale: 77756158c7 | (Nicholas Clark)++ | src/core/str_hash_table.c
If two threads "grow" the same hashtable concurrently, we must `oops`.

User threads are responsible for ensuring that they don't access MoarVM hashes concurrently, with mutexes or other concurrency primitives.
If they ignore this there is the potential for VM-level memory corruption and crashes (or worse). Growing hashes is rare, hence we afford the small performance hit of using atomic operations to detect if two threads attempt to reallocate the same hash at the same time, and exit with an informative message if so. (At the point we detect this we can't actually recover as we have a double free.)