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

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 22 19:36:53 UTC 2014

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.

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

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140422/fb092bef/attachment.htm

More information about the Vm-dev mailing list