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
Unfortunately, lots of issues :(. Some are:
Use of sint/uint types not done consistently (plain int is still 32 bit).
Use of int constants instead of long ints produces warnings (e.g. in shifting operations).
WordFrom/ToInt must perform checks.
Probably missing overflow checks elsewhere when going from word to (32 bit) ints.
Header encoding/decoding is fundamentally broken (GetSize for a 3 word block returns 2).
Big tags have to be moved from language layer into SEAM proper, to maintain platform independence for pickles.
Want to have 63 bit integers besides 31 bit ones, e.g. for tags or other languages.
Jitter won't work at all.
In a thread on the Oz users' list, Joachim Durchholz gave a nice 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 http://weblogs.mozillazine.org/roadmap/archives/005716.html
-- Thomas 2004-07-23