[armedbear-devel] Isolating ABCL in OSGi

[Alessio Stalla]

On Wed, May 19, 2010 at 2:01 PM, Mark Evenson <evenson at 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