Re: Some object serialization problems for discussion(3)-ObjectInputStream

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <address@hidden> writes:

Bryce> Yes, In this case I dont see why it shouldn't be done in Java
Bryce> unless there is a compelling performance advantage in doing
Bryce> otherwise. In fact I suspect that all of Serialization can be
Bryce> implemented in pure Java, it is probably just for legacy
Bryce> reasons that we have native methods in there at all. This would
Bryce> require some significant reworking of the code but I think it
Bryce> would be worthwhile.

I completely agree.  And, if there are performance reasons that we
might want native code in libgcj, I'd still like to see us merge as
much code as possible.

Bryce> One thing I know we'd love to do is to port ORP to run on the
Bryce> libgcj runtime. This would mean using the ORB JIT with libgcj's
Bryce> GC etc. This will allow JIT'ed bytecode to be mixed with
Bryce> pre-compiled object code. We already do this with libgcj's
Bryce> interpreter so in principle it should not be hard to implement,
Bryce> but we'd need to change ORP to be compatible with GCJ's object
Bryce> and vtable layouts, and I don't know how difficult that would
Bryce> be.

I looked at this a bit a while back (more than a year ago, I think).
These comments are based on that look; I haven't followed ORP closely
enough to know whether these things still hold.

ORP has the nice feature that the JIT asks the VM for information
about object layout, GC interface, etc.  So interfacing the JIT to
libgcj mostly requires writing a bunch of wrapper functions with the
right names.

Right now in libgcj we have an ad-hoc method for associating
interpreter data with a class and/or method.  We would need to
generalize this (a good idea anyway) so that ORP can also do something
intelligent.

Exception handling is the one problematic area I know of.

Well, there's also debugging.  That is much harder though.

Tom