[Vm-dev] [Pharo-dev] Iceberg with SSH on Linux

[Eliot Miranda]

On Thu, Mar 30, 2017 at 8:20 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Alistair,
>
> On Thu, Mar 30, 2017 at 9:32 AM, Alistair Grant <akgrant0710 at gmail.com>
> wrote:
>
>> Hi Eliot,
>>
>> On 30 March 2017 at 18:15, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> >
>> > On Mar 30, 2017, at 2:58 AM, Pavel Krivanek <pavel.krivanek at 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
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170330/9eecd633/attachment-0001.html>