Last updated at 12:47 am UTC on 17 January 2006
on 17 February 2003, Eric Merritt asked:
What is the state of the development of J5?
Ian Piumarta answered to the list:
I wanted make a version that worked on Mac for Dan to play with and the easiest route appeared to be to make it work on OS X which he was planning to install. Making j5 work on OS X meant making the Unix VM work on OS X, but that particular "subproject" got slightly out of hand and finally turned into a significant part of the hacking I've done during the last 5 or 6 months.
The current non-optimising compiler generates native code with all the hooks, profiling, recompilation triggers and support in place to do adaptive compilation based on runtime type feedback. (I was about to embark on the first round of adaptive compilation when I became distracted by OS X.) The emphasis is on reducing compilation time to an absolute minimum: what's important is generating code for lots of methods quickly (compilation shouldn't introduce any detectable pauses in execution) but which includes profiling (to record type, sender and frequency information to drive an optimising compiler). The real benefits come from recompilation using this optimising compiler, once runtime type behaviour is known, whose emphasis is on producing the fastest possible code at the expense of compilation time. Since this compiler is invoked far less frequently than the non-optimising one, its longer compilation times shouldn't introduce detectable pauses either.
The non-optimising compiler already produces stable code(where "stable" means I don't know how to crash the code by writing bizarre methods, abusing contexts or exceptions, etc., within the image) for PPC and 386. The first part of the optimising compiler was the next thing on the to-do list when OS X came along and preempted it.
I checked it out for you here: http://www-sor.inria.fr/~piumarta/squeak/unix/j5
Although I don't suggest you try this at home, the above could be dropped into a 3.2 tree (next to the "platforms" and "src" dirs) and will build a working j5 (provided the regular VM has already been built in a dir called "bld" at the same level). It generates code for PPC on Unix and 386 on Unix or Windows. (It probably works with the 3.5 tree too, modulo the Quartz code not bothering to look for "j_interpret" before launching the interpreter, so my objective of making it work on Mac OS might already have been met. Some trivial additions are required to the win32 tree to make it work, but they're outside the tree that I checked out.
The above directory contains the answers to any and all questions you might have regarding j5, albeit in an extremely undigested form. ;)
I'm hearing encouraging things about Anthony's latest run at his closure work. When I get round to picking up j5 from where I left off I'll probably start by looking at what he's been up to and adapt j5 to work with it instead of with an unmodified "traditional" image.