Smalltalk › Squeak › Squeak VM

Re: [Pharo-dev] Iceberg with SSH on Linux

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Eliot Miranda-2

Re: [Pharo-dev] Iceberg with SSH on Linux

On Thu, Mar 30, 2017 at 8:20 PM, Eliot Miranda <[hidden email]> wrote:

Hi Alistair,

On Thu, Mar 30, 2017 at 9:32 AM, Alistair Grant <[hidden email]> wrote:
Hi Eliot,

On 30 March 2017 at 18:15, Eliot Miranda <[hidden email]> wrote:
>
> On Mar 30, 2017, at 2:58 AM, Pavel Krivanek <[hidden email]>
> 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/32f321583c69ca27e61ffaff6decc2a3e4b6ca5e

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/5418a415e9297f601f6d57ee732fd7fd942da08c

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

_,,,^..^,,,_

best, Eliot