On Tue, Jul 19, 2011 at 05:01:09PM -0400, Marc Feeley wrote:
On the #gambit IRC channel people were asking about the Gambit "roadmap".
Over the past months, the time I had to work on Gambit has been limited by another project, the implementation of a family of research VMs for JavaScript (interestingly a lot of the experience I have gained through Gambit is being applied to that project and there will be some returns to Gambit down the line). Our first paper has just been accepted to the Dynamic Language Symposium 2011.
Recently, I have been improving the Gambit REPL application for iPhone/iPad. The main new feature is the implementation of a public script repository, in fact the Gambit wiki, to upload and download scripts (the download requires a manual copy/paste operation to respect the Apple developer agreement).
I plan to resume work on the x86 back-end after that is done. My objective is to have a working system in 4 months. Performance of the generated code should be 2.5 to 5 times the performance of the C back-end on average, depending on the benchmark.
I will also resume work on supporting parallel execution. As a first step, the Gambit runtime will be refactored to allow multiple instantiations in the same OS process (to have multiple Gambit "VMs" run side-by-side, possibly communicating using sockets, or pipes, or some message-passing mechanism). That should not be too hard to do given the current structure of the runtime (each C module has a single "module" structure containing its global state).
Once that is done, the system will evolve to allow several OS threads to run in the same instance of the Gambit VM. For this to work, Gambit's current thread scheduler needs to be modified to multiplex the execution of the Scheme threads on multiple OS threads. In essence, the runtime system will start as many OS threads as there are processors (or cores) and the Scheme threads will be multiplexed on those OS threads. Gambit already manages stack allocation in a way that is easy to extend to multiple OS threads. Basically, each OS thread will allocate stack frames in a section that is specific to that OS thread. This eliminates contention for the stack and fragmentation of the stack memory. The Gambit synchronization primitives, such as mutexes and condition variables, need to be reimplemented to use the OS thread synchronization primitives. That is not conceptually hard, but it must be done very carefully otherwise there will be subtle bugs that could haunt the system for a long time. Another important issue is the GC. It too has to be made parallel otherwise the performance of parallel programs will suffer.
The world has long needed a good, practical, flexible GC that can handle parallelism. The days that each programming language had to have its owm specialized and incompatible GC should be numbered. But running the GC in parallel with the program it's collecting is costly without hardware support.
The C-- project has some ideas how to manage the interface between a GC and its language. They may be right on how to do it, but I don't think their interfacing has yet been tested on anything parallel.
-- hendrik
Thanks to a new research grant from Mozilla, I am reassigning some of my research money to work on Gambit. So if you are interested in Gambit and dynamic languages, and you are thinking of doing graduate studies (at the masters, PhD or postdoc level) on the implementation of dynamic languages, then please get in touch with me. I have openings!
Marc
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list