[Vm-dev] VM on Solaris (was: Camera sig fault on 64 bits machines.)

Wed Apr 23 22:14:45 UTC 2014

Hi Andreas,

On Wed, Apr 23, 2014 at 9:35 AM, Andreas Wacknitz <a.wacknitz at gmx.de> wrote:

>
> Thanks again Eliot,
>
> First, I solved the pthreads problem under OpenSolaris. While Solaris 10
> doesn’t need special user privileges for thread control (at least within
> the same thread policy I guess),
> users under Solaris 11 (and thus OpenSolaris) need the privilege
> „proc_priocntl“ to be given by an administrator.
> (For those who are interested: usermod -K defaultpriv=basic,proc_priocntl
> andreas)
>

This is a pain :-).  You could either assume that people can always get the
necessary permission and go with the threaded heartbeat (my preferred
suggestion) or provide two VMs (always tedious).

More below…
>
> Am 22.04.2014 um 22:31 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>
>
>
>
> On Tue, Apr 22, 2014 at 1:10 PM, Andreas Wacknitz <a.wacknitz at gmx.de>wrote:
>
>>
>>
>> Am 22.04.2014 um 21:36 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>
>> Hi Andreas,
>>
>>
>> On Tue, Apr 22, 2014 at 12:05 PM, Andreas Wacknitz <a.wacknitz at gmx.de>wrote:
>>
>>>
>>> This evening I further dealt with the problems on OpenSolaris
>>> (openindiana).
>>> I finally got a pthread version running without superuser rights. But I
>>> don’t know whether this will really work (ATM it does for me)
>>> because I removed the call to pthread_setschedparam in beatStateMachine
>>> leaving the heartbeat thread with the same
>>> priority than the vm thread.
>>
>>
>> Alas, that will not work -(.  As soon as the image enters into a hard
>> loop (e.g. [true] whileTrue) the heartbeat thread will be blocked and the
>> VM will never break out of the loop.
>>
>>
>> How can I check this blockage? I started the VM with --pollpipe 1 and
>> then [true] whileTrue in a Workspace. The GUI is blocked but the pipe is
>> still rotating.
>>
>
> Can you interrupt with ctrl-period?  If not, then I don't understand how
> the pip is still rotating :-).  If you can, then you're not blocking the
> system.  Try e.g. [[true] whileTrue]  forkAt: Processor highestPriority.
>
> Yes, I can do that in both (with and without higher priority) BUT not when
> running this with highestPriority (again in BOTH versions!).
>

Oops That's right.  It should be just "[[true] whileTrue]  forkAt:
Processor userPriority + 1".  Obviously one can't interrupt something
running higher than userInterrupt priority.  Sorry, I was asleep.

You are running the JIT right?
>
> How to tell for sure?
>

vm -version

If it includes a CoInterpreter line you're running the JIT.  e.g.
McStalker.macbuild$ oscfvm -version
/Users/eliot/Cog/oscogvm/macbuild/Fast.app/Contents/MacOS/Squeak
4.0 4.0.2894 Mac OS X built on Apr 14 2014 17:02:16 Compiler: 4.2.1 (Apple
Inc. build 5666) (dot 3) [Production VM]
CoInterpreter VMMaker.oscog-eem.674 uuid:
eefd603d-9638-4ad8-99c0-4ee12e87d49d Apr 14 2014
StackToRegisterMappingCogit VMMaker.oscog-eem.674 uuid:
eefd603d-9638-4ad8-99c0-4ee12e87d49d Apr 14 2014
VM: r2894 http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2014-04-14
15:32:11 -0700
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins

> I started the VM with —trace. The last log is
> „IRBytecodeGenerator>>from:goto“.
> The pipe is still rotating but ALT-. does not break the loop (maybe a
> problem of my Pharo image?; I will try later with a Squeak image).
>
>
> I tried to replace the pthread_setschedparam call with a similar
>>> pthread_setschedprio call but
>>> with no luck (same problem: failed call with "Not owner"). I don’t know
>>> wether this is a general problem with the pthreads implementation
>>> on Solaris or just a problem with the gcc version (4.4.4) coming with
>>> the openindiana distribution I am using. Maybe this works only
>>> with the compilers and libraries that is delivered by Oracle (Solaris 10
>>> ships with gcc 3.4.3; Solaris Studio has its own compilers).
>>>
>>
>> It's too do with pthreads.  Nothing to do with the compiler.  On some
>> implementations it requires special permission to create threads with
>> different priorities.  That used to be the case on linux and it appears to
>> be the case on OpenSolaris.  Hence one is stuck with the itimer heartbeat.
>>
>> Is there any implementation actually using sqUnixITimerHeartbeat.c?
>>
>
> Yes, but unhappily.  We use it at Cadence because we have customers on pre
> 2.6.12 kernels.  We have to e.g. switch off the heartbeast around certain
> external calls.
>
> I am still wondering about where the necessary sleep call will be
> generated in this case. I will check your latest VM sources. Maybe PharoVM
> is different here…
>

Where is there a necessary sleep?

I don’t think that Solaris has special problems here.
>> Also, I cannot imagine that this situation is so uncommon that nobody
>> else got it before SqueakVM. A higher prioritized thread should be possible
>> for ordinary users.
>>
>
> I definitely wasn't the case on linux.
>
> I haven’t tried to build the VM for Solaris 10 yet but I have tried a
> multi-threaded example program I found in the web. This example program is
> running 4 threads for computation
> and does not run under OpenSolaris (same error code like the SqueakVM is
> generating) but it runs without hassles on Solaris 10 SPARC. So I guess
> Solaris 10 will run the
> two-threaded SqueakVM without problems.
>

sigh...

>
> Best regards,
> Andreas
>
>
>

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140423/d5c34d7c/attachment-0001.htm