On Thu, Mar 30, 2017 at 8:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair,
On Thu, Mar 30, 2017 at 9:32 AM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Eliot,
On 30 March 2017 at 18:15, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mar 30, 2017, at 2:58 AM, Pavel Krivanek pavel.krivanek@gmail.com wrote:
Yes, the same priority. See:
The VM may have issues with clock jitter due to the heartbeat thread not running at elevated priority.
It better /not/ be. This is wrong. The heartbeat thread /must/ run at
a
higher priority for the VM not to lock up when it becomes compute
bound. I
thought the resolution was that the VM /will/ try and raise the
priority if
the heartbeat thread but will /not/ exit if it fails. This is /very/ different from not trying to raise the priority at all.
As Esteban wrote, the vm is trying to raise the priority. You can see the change at:
https://github.com/pharo-project/pharo-vm/commit/32f321583c6 9ca27e61ffaff6decc2a3e4b6ca5e
I'd like to just make sure I understand your comment correctly:
Are you saying that the VM will lock up if it gets in to, e.g., an endless loop, so that Ctrl-. fails to interrupt. Or is it more serious than that? Can the VM become locked up for just a long running process (I guess it will be locked while the process is running, but will eventually go back to normal once the process completes)?
The issue is that delays are recognized by periodically checking the time against the next delay expiry. It is the heartbeat thread that causes JITed Smalltalk code to break out of its execution to check for events, including the next delay expiry. So if the heartbeat is at the same priority as the JITed Smalltalk code, and the Smalltalk code is in tight enough a loop (one that does not provoke a GC, does not do any process switches) the heartbeat thread will not run and the delay expiry will never be tested for.
Something like the following should run forever if the heartbeat has the same priority as the VM thread (and should be tried in a headless configuration too):
[| infiniteLoop | infiniteLoop := [| sum | sum := 0. [sum < 10] whileTrue: [sum := sum + (sum even ifTrue: [1] ifFalse: [-1])]] newProcess. infiniteLoop resume. Processor activeProcess priority: Processor activePriority + 1. (Delay forSeconds: 1) wait. infiniteLoop terminate. Processor activeProcess priority: Processor activePriority - 1] timeToRun 1001
Also, a change was made to the travis test setup in:
https://github.com/pharo-project/pharo-vm/commit/5418a415e92 97f601f6d57ee732fd7fd942da08c
The comment is: "No need to raise rtprio limit anymore"
From your comments above, this doesn't seem accurate.
Right. What seems to occur is that certain linux distress don't require a conf file to allow raising the priority of a thread. Remember that rtprio is not the issue. We only require that the heartbeat thread has higher priority than the VM thread.
I'm in the middle of adding some details to the text that is printed out by the threaded heartbeat vm, and from what you're saying, maybe we should add some more warnings.
The VM should (& I believe already does) print an error if the attempt to raise the heartbeat thread priority fails. My underatanding is that the positive change is simply not to exit if the attempt fails.
The resolution I thought we had reached means that if correctly
installed
the VM can work correctly, and will continue to work correctly if and
when
linux removes the annoyance of the conf files. The resolution you
describe
Pavel (I hope inaccurately) means the threaded heartbeat VM will never
work
correctly.
Thanks, Alistair
_,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda