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

[Bryce McKinlay]

"Wu, Gansha" wrote:

>      libgcj implements callReadObject, callWriteObject in java, but classpath 
> demands native to
> do them;

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

>       BTW, because of legacy problems, we couldn't port to libgcj's 
> implementation so easily.
>       We really like those changes like BigInteger, libgcj removed native 
> dependency in BigInteger, and
>  we hope BigInteger (and the like) in classpath will be merged back into 
> classpath ASAP;

It should be trivial to merge the BigInteger stuff into classpath. For 
java.util.zip as you know it is more
difficult for us due to the native code dependency. I believe there is now a 
pure-Java implementation of this
which we should look at for classpath if copyright assignment etc can be taken 
care of.

>      We also like libgcj will add those parts classpath haven't implemented 
> into classpath, e.g,
>  java.util.zip.*, it's very important to run some biz apps;
>      But to those which involved changes of native interfaces, it's a burden 
> for us to change VM part.

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

regards

Bryce.