<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Denis,<div dir="ltr"><br><blockquote type="cite">On May 5, 2020, at 12:39 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span><div dir="ltr">Hi.<div><br></div><div>I encounter interesting behavior of process termination. I can't reproduce it locally but I have constantly failing test on Pharo CI (as part of full test suite) due to following conditions:</div><div></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>ended := false.</div><div> process := [ Processor activeProcess suspend. ended := true] </div><div> forkAt: Processor activePriority + 1.</div><div> self assert: process isSuspended description: 'should be suspended'.</div><div><br></div><div> process resume.</div><div><br></div><div> self assert: ended description: 'last statement is done'.</div><div> self assert: process suspendedContext pc equals: 0</div><div><br></div></blockquote><div>When I try to run it locally the pc is always greater than #startpc. </div><div>On CI the test very rarely behaves same way. The process is always finished (#ended is true) but in most of runs the pc of #terminate context is somehow reset to zero (probably related to the order of overall test suite). . </div><div><br></div><div>In Pharo succeed process ends here:</div><div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">terminate<br> ...........</blockquote></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div> self isActiveProcess ifTrue: [</div></blockquote></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div> thisContext terminateTo: nil.</div></blockquote></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div> self suspend ]</div></blockquote></div></blockquote></blockquote><div><br></div><div>It seems that Context>>#terminateTo: can reset the pc to zero under some condition (jitter related?).</div></div></span></div></blockquote><div><br></div>The JIT maps machine code PCs to bytecode PCs whenever the pc is accessed of a context which is running JITted code. If the mapping fails then 0 may be returned. But this is evidence of a bug in the mapping computation.<div><br><blockquote type="cite"><div dir="ltr"><span><div dir="ltr"><div>So I wonder what could be the explanation?</div><div><div><br></div><div></div><div>I would like to understand this behavior before I will propose the change for Pharo (#isTerminate implementation needs to be fixed).</div></div></div></span></div></blockquote><div><br></div>There are exhaustive tests which test all pairs of mappable PCs map correctly in VMMaker.oscog. Those tests could be run against all methods in Pharo. The tests use in-image compilation to produce the JITted methods.</div><div><br></div><div>But if there is a if such that either the tests are deficient or the VM is somehow suspending at a non-suspension point, the tests will not shoe the problem.</div><div><br></div><div>I would work in trying to reproduce the problem, especially in an assert-enabled vm run on the command line. Then you will see issues in the mapping algorithm well before the mapping algorithm fails and answers a zero pc.</div><div><br><blockquote type="cite"><div dir="ltr"><span><div dir="ltr"><div><div></div></div><div><br></div><div>Best regards,</div><div>Denis.</div><div><br></div></div>
</span></div></blockquote></div></body></html>