Issue #14867 has been updated by k0kubun (Takashi Kokubun).


> The other thing is MJIT multi-threading/synchronization seems tricky-to-debug right now, and making it event-based should be beneficial for reliability.

Yeah, if the performance regression by moving to event-based implementation is not so big, using that would be reasonable. I want MJIT implementation to be reliable too.

> So checking one extra global variables with RUBY_VM_CHECK_INTS introduces a measurable perf hit?

Correct. With Optcarrot on my machine, the trunk --jit is 87fps at maximum, extra global variable check on all RUBY_VM_CHECK_INTS was 83fps, and disabling the check on JIT-ed code (only VM checks it) was 84fps. Copying inline caches on enqueueing was 80~84fps-ish.

> Ah, so the waitpid from #system is on /bin/rm (I missed that earlier) 

For http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1431394, yes. Others http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1431775 http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1430875 are on waitpid for different things.

> Is `rm' stuck (NFS, drive error, etc)?

Unfortunately I can't know that now. I'll try to check that once I see another failure notification while I'm online. But at least I can say that it looks not stucking on similar but non-MJIT CIs.

> But yes, I also wonder if there's a bug in the current system+waitpid implementation.
>
> Perhaps #system needs to use similar mechanism as mjit_worker to prevent work-stealing.
>
> the self-pipe/eventfd would've woken native_ppoll_sleep, anyways.

I see. So that would be the direct fix for this deadlock.

> System-level signal handler is only registered at startup, and Ruby Signal.trap handler is process-wide and only runs in main thread. native_ppoll_sleep can be called by any thread (which exclusively acquires sigwait_fd).

Thanks for the explanation around that. That helps my understanding. 

> (But I need to fix a car problem, first :<)

Oh, sorry to hear that :<

----------------------------------------
Bug #14867: Process.wait can wait for MJIT compiler process
https://bugs.ruby-lang.org/issues/14867#change-74653

* Author: k0kubun (Takashi Kokubun)
* Status: Assigned
* Priority: Normal
* Assignee: k0kubun (Takashi Kokubun)
* Target version: 
* ruby -v: 
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
If Ruby tries to wait for any child process, MJIT's gcc/clang process could be caught by the method call. It's not convenient for both Ruby's user and MJIT worker thread, so Process.wait and its families should somehow avoid waiting for it.

---Files--------------------------------
0001-hijack-SIGCHLD-handler-for-internal-use.patch (13.8 KB)
JIT-test-all.log (39.9 KB)
mjit_test-all_63796.log (40.4 KB)
config_ruby-loco_mingw.log (27 KB)
test_jit_results.txt (41.2 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>