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

[Mark Wielaard]

Hi,

Most of the Intel/Orp patches have now be merged and checked in. I just
applied a lot "as is" but some things were done a bit different. I made
sure to create extensive ChangeLog entries for all changes so please
check the ChangeLog and the actual CVS diffs for more details.

Here are some questions/issues with the remaining things. I already
mentioned some of these when the patches were submitted or in previous
emails. Just repeating myself to give the complete picture.

There are some calls for volunteers or just suggestions for things to do
in the future. Please volunteer for any of these tasks and I will be
happy to send you more info patches :) But even just a simple "Good/Bad
Idea" reply would be appreciated.

Things not applied yet
======================

- 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?

- 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.

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

- 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.

Suggestions for the future
==========================

- I applied all of the initial size for StringBuffer patches since they
seems to be a bottleneck for performance. Initializing the StringBuffer
to something like at least half the expected size seems good practice in
general. I saw that GCJ has unsynchronized version of StringBuffer that
can be used by library code that knows it is save since it has the only
reference to the buffer.
Another thing to look at it the following idea of reusing StringBuffers:
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/0,1701,2488,00.html
(The article claims a speed improvement of 65%)

- I rewrote most of URLClassLoader based on the submitted patches and
added support for CodeDomains, Packages, (hopefully) newInstance()
Permissions and some bug fixes for IK.VM.NET.
One thing that we lose is an optimization that was in the Intel/Orp
patch that always started searching the most recently used jar/file
location. Sadly that is an optimization that is almost always correct,
since classes are mostly loaded in groups from the same location, but it
is not always correct since URLClassLoader guarantees that the locations
are searched in order (so a location/jar at the front may patch/override
a class/resource found in a later location/jar). We may want to
implement something like:
<http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#JAR%20Index>
which makes caching locations safe and speedy.

- In the future we should make the SystemClassLoader (actually the
application classloader) a subclass of URLClassLoader and do all caching
in URLClassLoader. The VMClassLoader would then only be used to load the
bootstrap (Classpath and VM) classes. This would also make the
difference between a "null" and System/Application ClassLoader more
clear. Note that I did apply the change to return null for java.* - and
gnu.java.* - classes but not the one for changing all "null" loaders to
the systemClassLoader. I also tried to make more clear what should be
explicitly implemented by the VMClassLoader as bootclassloader and what
can be delegated to the application/systemclassloader to prevent
circular class load call chains. But I am sure that I missed some
things. I will concentrate on this and document it better next week.

Cheers,

Mark