Porting VM to Linux x86

[GoogleCodeExporter]

The problematic areas are likely to be:
    - calling conventions/spaghetti stack support
    - memory management
    - thread management

Original issue reported on code.google.com by David.Gr...@gmail.com on 22 Sep 2006 at 9:53

[GoogleCodeExporter]

Original comment by David.Gr...@gmail.com on 22 Sep 2006 at 10:12

• Added labels: OpSys-Linux

[GoogleCodeExporter]

As posted to the list, I am close to having base level support for linux. As to 
the
issues mentioned in the original comment, here are my initial approaches
- calling conventions: primitive calling conventions are no different from 
those for
the Windows version, since both caller and callee can agree on a common 
convention.
For DLLs the story is a little different. The Windows APIs all use stdcall, 
whereas
Linux libraries generally use cdecl. The DLL call support was assuming that all 
DLLs
were stdcall. To work around the issue and support both stdcall calls on 
Windows and
cdecl calls on Linux I wrapped the DLL calls with an extra synthetic stack 
frame to
ensure that the esp/ebp get set back to the original locations. So far this 
appears
to work under both Windows and Linux (I can run the image under Windows, use dev
tools as normal, save image, file out etc. all without noticeable problems, and 
I can
run the deterministic test under Linux). That said, I have concerns over NLRs 
since I
am not pushing a return address.
- memory management: simple malloc/free (actually valloc to give page aligned
allocations) As far as I am aware, there is no direct Linux equivalent of the 
Windows
Alloc/Commit/Reset/Free memory operations. Of course we could write our own, 
but that
seems quite a big job and valloc/free seem OK for now, with one exception. For
reasons that I don't quite follow the reservation of memory is disconnected 
from its
release (ie. reservation is performed by ReservedSpace, release is performed by
VirtualSpace). Since the initial allocation is split in two for old and new 
spaces
one of the virtual spaces is unable to free its memory. This was causing the VM 
to
crash on exit, after running the tests - since valloc didn't alloc the address, 
free
cannot free it and this results in a SIGSEGV fault. For now, I am keeping a 
register
of allocations and only freeing those that have been allocated. This could need
revising subsequently if the lower half of a reserved space is freed without the
upper half, as clib's free will free the lot.

When I include recompileWorld in the test under Linux the garbage collector 
blows up
with a "pointer reversal should have taken place" assertion failure. I haven't
debugged this yet.
- thread management: using the NPTL pthread library. The thread id's I have 
wrapped
in a Thread class which is private to os_linux.cpp (by which I mean that allow 
other
source files can see the Thread class, no operations are exposed outside of
os_linux.cpp). A similar approach is taken to Event (wrapping a condition 
variable, a
mutex and a flag) and DLL (wrapping a library handle).

My approach generally has been opportunistic - I have only implemented those
operations on os:: required to allow the tests in deteministicallyTestSystem to 
pass.
 Other methods are left as stubs.

Similarly, in the image, I have only replaced those DLL calls necessary to make 
the
tests pass. Since we have no mechanism currently for bootstrapping an image, I 
am
using a common image for both Windows and Linux. To make this work I have 
created 2
variants of the Platform class - Win32Platform and UnixPlatform - together with
related file classes as necessary. Platform then becomes an alias to the 
appropriate
class and the last step of the VM bootstrap code populates the Platform 
association
with the appropriate platfrom, the name for which is retrieved from a new 
method on os::.

Due to these changes, the revised VM will not work with existing images, nor 
will the
new image run on existing VMs.

For now, I have excluded recompile world from the system test in the image 
included
in the attachment. Once I have figured out what is causing GC to barf, I will 
post a
revision.

The attachment is based on prunedtree's GCC changes with a few bug fixes, and 
Dave
Raymer's Linux build files.

Original comment by StephenL...@gmail.com on 18 Jun 2007 at 8:17

Attachments:

• strongtalk-r36-noasm8.zip

[GoogleCodeExporter]

I'm trying to download the attachment but everytime I get "disconnected by the 
server" at random byte counts.  This doesn't happen if I download from other 
Google 
Code places.
Is it possible to publish the code somewhere else?  Thanks

Original comment by dmr...@gmail.com on 9 Jul 2007 at 4:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

mirror:
  http://www.sendspace.com/file/n2mbp8

Original comment by prunedt...@gmail.com on 5 Aug 2007 at 2:22

[GoogleCodeExporter]

Hi

I am also trying to download this precious porting code, but to no avail. Would 
it be
possible to repost it please?

Original comment by vincent....@gmail.com on 14 Sep 2007 at 11:53

[GoogleCodeExporter]

I don't know why people are having problems with this file. I just managed to
download it without a hitch. In any case, I've uploaded the file to sendspace 
again.
It can be retrieved via the following url http://www.sendspace.com/file/q5f4d4

Original comment by StephenL...@gmail.com on 5 Oct 2007 at 9:07