On Wed, May 19, 2010 at 2:01 PM, Mark Evenson evenson@panix.com wrote:
On 5/19/10 9:42 AM, Alessio Stalla wrote:
[…]
I'm afraid that disposing the Interpreter and starting a new one is not the same as rebooting ABCL. Most of the state is reachable from static fields; the list of packages is static, for example. That said, System.exit() should really be removed in favor of an Interpreter.quit() or something like that, which will call System.exit() in the default case, but may be overridden in order to do other things in certain environments. If you want to have multiple instances of ABCL running in parallel, or even simply to restart it without restarting the JVM, you have to run each instance in a dedicated classloader. If, as I have understood, you intend to use ABCL as a service provider accessed through some kind of "remoting" layer (even when on the same machine as the other modules), then it's perfectly fine to have ABCL locked in its own private world, since all communication with it will be through message passing - *if* the type of those messages is a class which is shared among all the ABCL instances, i.e. loaded by a shared parent classloader, i.e. not LispObject. I'm talking of the actual Class of the message here - a byte[] containing a serialized LispObject would be fine.
How does one (de)serialize a LispObject to byte[]? We don't implement the java.io.Serializable contract so as far as I can tell, we need a fair amount of implementation work here. Or have I missed something simple?
We can't now, but in the past I did implement working serialization for simple LispObjects - numbers, characters, strings, and conses at least. Functions are problematic. Symbols are also tricky to get right because it's not clear where to draw the line: from a given symbol you can reach half of the Lisp world - the symbol might have a global binding, a function binding, a plist... and it certainly has a link to its home package and thus transitively to all symbols in that package! I think I only serialized the symbol name + home package name, and on deserialization I interned it in the specified package, without carrying any other data that might be associated with the symbol. That basically only preserves symbol identity across different ABCL images, with a caveat: for uninterned symbols, if you want several occurrences of the same symbol to be serialized preserving identity, you have to serialize them all at once, that is:
serialize(cons(#:foo, #:foo)) -> cons( #:foo', #:foo' )
but
cons(serialize(#:foo), serialize(#:foo)) -> cons( #:foo', #:foo'' ) with #:foo' =/= #:foo''
My code was an attempt at implementing save-image with Java serialization, which proved to be hard. However, I think I can easily bring some of that code to the current ABCL, covering at least the subset of Lisp object types which can be serialized without much effort.
hth, Alessio