As I needed a small GC for GBA programming I wrote it, it was pretty funny. I used a mark & sweep classical and simple algorithm. The most difficult part was about data structures. Free blocks are kept in a linked list called “free list” and usually the GC allocate theses lists using malloc() , but since the GC Light is operating on a fixed size memory (the 256Ko of external GBA memory), mallocated and GC’ed memory overlaps ! One easy way would have been to keep a fixed percentage of the memory available for storing data structures but then you’re wasting too much space when memory is not fragmented or having not enough space to store a lot of very small fragmented free blocks, making the GC crash ! The best is to have the GC data structures interleaved with GC’ed allocated memory : after some tweaking it works pretty well, now I have to run the MotionScript VM with this new GC to check that nothing is broken (I need to remove some malloc’s in the VM) and after let’s check some fibonacci perfs on the real hardware !
I have my flashable GameBoy Advance ROM at home since few weeks now (it’s a 256MB EFA Advance). After reading the specs and thanks to the people at gbadev.org, I could make some little game demo that works on real hardware ! It’s quite fun to write game engines at such low level, but C really piss me off for the game logic… I definitly have to port the MotionScript Virtual Machine before doing any serious work, so I can use a higher level programming language such as MTypes. But at first I need a small and fast garbage collector since I’m pretty sure the Boehm GC will either not compile/not work on ARM processor or will have too much memory overhead for such a small device. And after all… reinventing the well is my favorite hobby !
A little more than one year ago, I was working on the Honsen project (right now freezed due to lack of time). The goal was to make a Flash-with-3D styled IE plugin so we needed a simple dynamicly typed programming language. I designed the language “MotionScript” and wrote the compiler using OCaml. The compiler was generating some efficient bytecode for the MotionScript Virtual Machine, with a memory model similar to OCaml (as well as 31bits fast integers) and was using the Hans Boehm Garbage Collector. It worked great, outperforming Python by a factor of more than 2 (and ActionScript by a factor of more than 25 !).
In last October when I started looking again at web languages (PHP and the likes) in order to choose a language for the upcoming Dinoparc.com website, I was quite stressed not to be able to find a high-level language with a good type system. Since Motion-Types was already working, I slighty modified the AS code generator to get a MotionScript generator (since syntax is 90% the same) so I can run Motion-Types on the VM. Then I put the VM inside a mod for Apache 1.3 webserver and added APIs in order to access CGI, MySQL, and some serialization for session objects. It was done quite fast and is now working very well on both Windows and Linux.
It’s not a PHP killer since it can’t be embedded directly into webpages and since Motion-Types have a high learning curve, but have several interesting features. In particular all the classes are compiled into a single bytecode file that is then deployed on the server (so you don’t put any sources on the server). The VM is loading the bytecode into memory with caching in order to reload it only if it hasn’t been modified. This way all statics (regexp, templates parsing, xml, mysql connection…) are initialized one time at loading and then when a page is requested the application entry point is called. Suit well with Apache 1.3 which use prefork instead of threads, but with entry point disabled it might work as well on Apache 2.0.