You didn't create a user profile yet. Select UserPreferences in the upper right corner to create a profile.

Clear message

Seam Development

This page is a notepad of ideas and to-do items to be considered in the development of SEAM. SEAM stands for simple extensible abstract machine and is a new virtual machine which supports execution of multiple languages. Currently, there is a language layer for Alice and a prototype language layer for the Java Virtual Machine.

Ideas and To-Do Items

64 Bit Support

(Moved here.)

I cannot compile SEAM 1.4 on Linux AMD64 architecture. There are lots of casting errors ("losing precision"). The default GCC used is 4.1. What a pity I cannot run it on Linux AMD64.

-- Shouxun YANG 2007-06-22

(Sorry for the late reply.)

SEAM used to build on AMD64, so I suppose this is primarily an issue with GCC 4.1, which we haven't tested yet. We'll investigate, thanks for pointing this out.

Also note that we released Alice 1.2 binaries for Debian/AMD64, which you could use ([WWW] http://www.ps.uni-sb.de/alice/download/debian/dists/stable/contrib/binary-amd64/). But there was too little interest to justify supporting it further.

-- Andreas 2007-07-14


In a thread on the Oz users' list, Joachim Durchholz gave a nice [WWW] explanation for a memory leak in Mozart. Objects may keep references to data allocated outside the garbage-collected heap; these data are kept live until a garbage collection occurs and they are finalized. Such external allocation areas need to be accounted for properly in the policy of when to perform garbage collections. We should think about such an interface for the SEAM store.

-- Leif Kornstaedt 2003-02-26 13:32:49

Memory Leak in Thread Creation

Similar to Mozart.

-- Leif Kornstaedt 2003-04-02 15:11:08

Blocking native calls

Currently, a call to a native function via the FFI blocks the engine. This is a fundamental problem for binding OS or library functions that may take an indefinite amount of time to complete (e.g. Gecode functions triggering propagation until a space is stable), or even block (e.g. all kinds of I/O operations).

There should be a possibility to perform selected native calls concurrently, for example by having Seam manage (a resizable pool of) additional native threads. The respective binding would be responsible for proper synchronisation. Such calls probably need to be interruptable in case the corresponding Alice thread gets killed.

Memory management of the GMP library

Currently, GMP is built into the Alice language layer. It should probably be put into Seam directly. We have to box gmp integers twice at the moment (The "stub" in a chunk, the chunk in a ConcreteRepresentation to support pickling and equality test); it would be better to have just a chunk with a special label that can be recognized by GC, pickler, and equality test. GMP ints are allocated using malloc (or whatever gmp uses internally); Mozart uses free lists, maybe we should do the same.

-- Guido Tack 2004-07-09 12:38:08

Mozilla 2.0 VM Collaboration?

There may be some possibility of collaboration? See [WWW] http://weblogs.mozillazine.org/roadmap/archives/005716.html

-- Thomas 2004-07-23

Port to Intel-based Macs?

Would SEAM port to the Intel-based Macs quickly? I'd love to run Alice on my machine, but the Mozart packages apparently don't work on Intel Macs.

-- Rod Price 2006-05-16

In principle it should, and we are looking into it for the upcoming Alice release. However, for such a release it all depends on the status of Gtk for Intel Macs :-(

-- Andreas 2006-05-17