swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Swarm-Support] strange error with java layer on 64 bit, 4 proc, xeo


From: Marcus G. Daniels
Subject: Re: [Swarm-Support] strange error with java layer on 64 bit, 4 proc, xeon, ubuntu
Date: Thu, 15 Jan 2009 14:33:35 -0700
User-agent: Thunderbird 2.0.0.16 (Windows/20080708)

glen e. p. ropella wrote:
I took this to mean that objc_msg_lookup(receiver, op) in sendmsg.c was
experiencing a seg fault.  But I put print statements in there and it
goes through the function and calls [receiver -op] just fine.
The usual problem with x86_64 and Java is the scenario where the Swarm
scheduler sends a message to a Java object in the `usual' Objective C
way (i.e. it does not send it directly through an FCall intended for a
Java destination).

Swarm, running in Objective C land, must forward this call.   The
process of forwarding involves pulling values from stack and registers
according to the type signature of the call (that information is in the
Objective C runtime).   This machine-dependent code is not up-to-date
for x86_64 platforms (neither Linux or MacOS X) and the compiler does
not accurately communicate these stack / register file offsets.  So in
essence what the compiler does is restated in these mframe macros.

One way to test this hypothesis, other than stepping through the code in
the debugger or with lots of printfs everywhere, is to remove all
scheduled calls and just have an initSwarm and nothing else.  A more
convincing way is to never using any scheduled call other than through
FCall (which has the benefit of giving you give you faster Java calls).

The code that needs attention (or replacement) are the mframe macros in
libobjc.   The work Scott Christley is doing would likely use standard
APIs for MacOS X, and there may be some similar possibilities with
GNUstep.   It's feasible but not trivial to write new code that follows
vendor ABI documents.

Marcus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]