github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:02 reportable6 left 00:03 reportable6 joined 03:10 evalable6 left, statisfiable6 left, sourceable6 left, tellable6 left, bloatable6 left, reportable6 left, nativecallable6 left, releasable6 left, quotable6 left, greppable6 left, bisectable6 left, coverable6 left, committable6 left, linkable6 left, notable6 left, shareable6 left, unicodable6 left, squashable6 left, benchable6 left 03:11 greppable6 joined, quotable6 joined, statisfiable6 joined, unicodable6 joined, tellable6 joined, nativecallable6 joined, squashable6 joined 03:12 shareable6 joined, benchable6 joined, reportable6 joined, releasable6 joined, evalable6 joined, bisectable6 joined, notable6 joined, bloatable6 joined 03:13 sourceable6 joined, linkable6 joined, committable6 joined 03:14 coverable6 joined 04:59 squashable6 left 05:01 squashable6 joined 06:02 reportable6 left 06:04 reportable6 joined 07:05 sxmx1 left
Geth MoarVM/master: 6 commits pushed by (Nicholas Clark)++ 08:47
08:48 linkable6 left 08:49 linkable6 joined 08:55 frost-lab joined 08:56 squashable6 left 08:57 squashable6 joined
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.)
10:18 linkable6 left
Geth MoarVM: nwc10++ created pull request #1492:
Try to trap concurrent hash accesses.		 10:18
10:19 linkable6 joined
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
10:28 linkable6 left
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
10:31 linkable6 joined
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
12:02 reportable6 left 12:04 reportable6 joined
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
12:32 linkable6 left
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
12:35 linkable6 joined
dogbert11 here's the script gist.github.com/dogbert17/36ff5b85...84e46d523a 12:36
MasterDuke nine++ 12:41
14:05 domidumont joined 14:41 frost-lab left 16:18 Kaeipi joined, Kaiepi left 16:23 Kaeipi left, sena_kun left, Kaeipi joined 16:25 sena_kun joined 16:43 zakharyas joined 18:02 reportable6 left 18:03 reportable6 joined 18:27 patrickb joined 18:33 domidumont left
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.
19:48 linkable6 left, evalable6 left, linkable6 joined 19:49 evalable6 joined
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.)
20:38 zakharyas left 21:12 patrickb left 22:24 dogbert11 left 22:25 dogbert11 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!