Re: [Swarm-Support] Max OSX and Java

[Bill Northcott]

On 23/04/2004, at 7:02 AM, Pascal Zumkehr wrote:
> i experienced the same problem as stephen marsland on march 30  
> (http://www.swarm.org/pipermail/support/2004-March/014063.html),  
> allthough i installed the patched gcc (gcc_os-1555_3.4b.pkg.sit). is  
> there any solution for this problem?
>
> furthermore, when compiling heatbugs, there is an error for an invalid  
> constructor call on FArgumentsImpl  
> (HeatbugModelSwarm,swarm.Selector,boolean)
> in HeatbugModelSwarm.java. The valid constructor takes only the  
> HeatbugModelSwarm and the Selector, not the boolean. also in  
> jmousetrap, there are three invalid constructor calls on
> swarm.random.UniformIntegerDistImpl(swarm.defobj.Zone,java.lang.Object, 
> int,int)
> UniformUnsignedDistImpl and UniformDoubleDistImpl, where the Object  
> actually has to be an SimpleRandomGenerator.
> so after having fixed these, javacswarm works fine, and when running  
> javaswarm on either of the examples in the x11 terminal, the problem  
> described above occurs. with every new call the numer before 'abort  
> trap' increases by 7
> (in line /usr/local/swarm2.2/bin/javaswarm: line 1:   637 Abort trap).  
> sometimes the crowded lines after (Version -1601961796 doesn't match  
> runtime protocol version 2) are not printed in the failure message  
> (allthough the number is still increased by 7).
>
> i am using the swarmFeb04 binary package with osx 10.3.3, java 1.4.2,  
> and installed all the needed software provided by  
> http://banking.web.unsw.edu.au/w.northcott/. the required environment  
> variables are set.
> i hope having given all important information to help solving this  
> problem. thanks to all
I guess this would be a good opportunity to put out an update on the  
MacOS X port.

As far as I know the Objective-C libraries in the binaries I have  
posted work correctly.  There are probably a few small anomalies in the  
GUI but no show stoppers.

However, there are problems with anything involving message forwarding.  
 This affects the following situations:
1.  Using the forward feature in Objective-C which sends messages  
addressed to any unrecognised method of a class to the first 'forward'  
method it can find in the class hierarchy.  The root object has a dummy  
forward method which gives an unrecognised method error.
2. Using the FCall class to forward messages from Swarm Objective-C  
objects to code in other languages such as Java, COM etc..

Any application which uses either of these features is likely to fail  
not only on MacOS X but on any RISC processor based system.   (It  
breaks on MacOS X and Tru64 UNIX to my knowledge) The Java API for  
Swarm relies on these features and therefore must be regarded as  
broken.

We have now carried out extensive analysis of the causes of these  
problems and I think we have a good understanding of how to fix them.   
Unfortunately, the fix is not simple.  Previously, the problems have  
been kluged around within the Objective-C runtime by inserting  
processor/system dependent empirical fixes.  However, these fixes are  
highly system and compiler dependent.  So they keep breaking.

The underlying cause of the problems are some functions builtin to gcc  
for constructing and deconstructing stack frames for foreign function  
calls.  These were included originally to support the GNU Objective-C  
runtime (used by Swarm).  Unfortunately, this was done in a hurry, and  
these functions only work on x86 processors (and possibly SPARC with  
some version of gcc).  The gcc maintainers are aware of this.  However,  
their conclusion is that the gcc builtin functions are not fixable.    
They have now included in gcc sources the libffi library which can be  
used to make foreign function calls.  As of gcc 3.4, this library will  
build and work on MacOS X as well as a very wide range of other  
systems.

The time has now come to fix these problems for good by rewriting the  
parts of the GNU runtime (sendmsg.c) that use the builtin functions to  
use libffi instead.   There is not much code involved, but it requires  
programmers with a good understanding of calling conventions on a range  
of different systems to avoid incorporating anything which is system  
specific.  All the system specific stuff needs to kept in libffi where  
it belongs.

If we can get this done, there could be major benefits.  We should be  
able to greatly simplify the Swarm source code by omitting the avcall  
and libobjc stuff.  If it is done right, we have some prospect of using  
the Apple runtime on MacOS X and the standard GNU runtime on other  
platforms.  This would make it much easier to integrate with other  
software.

If anyone out there thinks they could help with this, please email me.

Meanwhile I am not prepared to waste time on any more temporary kluges.  
 So I think we have to regard call forwarding and therefore Java as  
broken for Swarm on any non-x86 platform.

Bill Northcott