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

[Eliot Miranda]

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.

You are running the JIT right?

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 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.

At least that was my idea when I changed the code to use
> pthread_setschedprio. Changing the prio while keeping the policy seemed
> reasonable.
>

If you can lower the priority of the main thread that'll work too.


> You /could/ try and implement the heartbeat in another process and use
> nice to change its priority.  I don't know how well that would work.  I've
> never tried it.
>
> As I wrote I already wrote a simple C program that does send a SIGALRM.
> It’s working albeit very slowly.
>
>
> Second, I needed to change the implementation of ioUpdateVMTimezone
>> because Solaris does not have time_t->tm_gmtoff.
>> There seem to be copies of this function in all three heartbeat files
>> with the one in sqUnixITimerHeartbeat.c working for those OS’s without
>> tm_gmtoff.
>>
>> NativeBoost doesn’t seem to work yet (at least UnixEnvironment>>environ
>> raises an error: „failed to get a symbol address: environ“).
>>
>> This VM gives me 686787391 bytecodes/sec and 80516849 sends/sec on my 6
>> years old Sun Ultra 24 (2,4GHz Intel Q9300).
>> I get similar values for the VM with pthread_setschedparam call and
>> superuser rights.
>> My 4 years old iMac (2,8GHz Core i5) gives me 829149797 bytecodes/sec;
>> 117122195 sends/sec.
>> So the results seem comparable.
>>
>> Andreas
>
> --
> best,
> Eliot
>
> Regards,
> Andreas
>
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140422/0a88ec4b/attachment-0001.htm