Re: Status update and some questions/suggestions about remaining Intel/Orp patches

[Brian Jones]

Mark Wielaard <address@hidden> writes:

> - Do we have any RMI expert on the list who could review these changes?
> (The original implementation was donated by Transvirtual, after they
> abandoned the code, but nobody has been maintaining it since :{)
> Maybe someone has RMI example applications to test against?
> I don't know that much about RMI and if there are no volunteers I will
> just apply the patches as is since I believe the Orp developers are the
> biggest users of this code and have tested it well.
>
> - java/io/Object*Stream.java. We had these classes merged with libgcj
> but they are diverging again. This is code I don't know much about and
> has some very subtle issues that are easy to get wrong. One thing I like
> about the libgcj version is that it has a lot less native methods and
> does more with reflection. That makes the code much more portable. Is
> there a (performance?) reason for using so many native calls? Also
> Jeroen Frijters just submitted a small patch that should be integrated.
> Any volunteers?

No expert here, RMI is used quite a bit in J2EE, and hence in JBoss,
so my guess is they have tested this in some way, the same for
serialization.  JBoss is LGPL (or was), so feel free to play with it.

I've been doing some work on serialization tests but I don't know if
Classpath + (any VM) is up to the necessary reflection to run the
tests.  Anyway the next release of japitools will have that, sometime
next week I hope.  I've not tried it with Classpath yet.

> - ThreadLocal changes. I have to look closer at the changes but one of
> the design decisions was to have all that inside the ThreadLocal classes
> since Thread is a VM class that might be (very) different between VMs.
> I recently submitted a suggestion for splitting Thread into a generic
> java.lang.Thread class and a VM specific java.lang.VMThread helper
> class. I will integrate the ThreadLocal patches while working on that.

M'kay. :)  

> - I couldn't find the native code implementation for
> vm/reference/java/lang/PlatformProcess.java.

Probably wasn't included, I don't think Classpath has native code for
Runtime.exec() yet.  Probably just "port" gcj CNI version to JNI.  I
assume for the moment that PlatformProcess is somehow related, should
it be in the VM interface?

> - I am not sure that the new Runtime.runShutdownHooks() is actually
> thread save or even needed. What are the conditions under which is is
> and may be called from a VM? How does it precisely interact with exit()?
> It looks to me that a VM should just call Runtime.getRuntime().exit() on
> a control-C.

There are things like this, and also in File you are supposed to be
able to register certain files for deletion when the VM
exits... probably hooks into the runShutDownHooks() somehow.

-- 
Brian Jones <address@hidden>