[armedbear-devel] Isolating ABCL in OSGi
alessiostalla at gmail.com
Wed May 19 12:27:39 UTC 2010
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' )
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
More information about the armedbear-devel