Re: GNU Classpath + JRVM

[Brian Jones]

John Leuner <address@hidden> writes:

> I've created two documents:
> 
> http://people.debian.org/~jewel//jikes/port_poc.html
> http://people.debian.org/~jewel//jikes/futurechanges.html
> 
> describing my work on porting the Jikes RVM to GNU Classpath (or
> vice versa).
> 
> The biggest issue is:
> 
> Where do we put these JRVM specific changes in Classpath?
> 
> You can view the changed Classpath files at:
> 
> http://people.debian.org/~jewel//jikes/files/vmclasses/

I've started taking a greater look at these changes for Jikes RVM.  

java/lang/Integer.java - changed TYPE to use VM_Type
java/lang/Double.java
java/lang/Byte.java
java/lang/Float.java
java/lang/Short.java
java/lang/Long.java
java/lang/Boolean.java

Would changing VMClassLoader.getPrimitiveClass(String type) to a
non-native function to call VM_Type work here instead?

All of the places where you either commented out or took out the
System.loadLibrary calls that are inside the 
`if (Configuration.INIT_LOAD_LIBRARY)' blocks seem unnecessary, you
can disable this code in configure using --disable-load-library if
you're not using any native methods at all.  In your case is it
necessary to selectively comments out these blocks based on the class
or package involved?

What is the reason for changing FileDescriptor to make the file
descriptor public and the constructor public?

A number of changes indicate that the VM wants to implement low level
details (usually where Classpath traditionally called native
methods).  I can see two options.  In the past, we have added such
classes to the VM interface and we can do this again even though it is
a much larger number of files.  Instead we could try using a
preprocessor rather than the explicit directory/file separation.

Even with just adding the files to the VM interface and moving them to
vm/reference/... there would still be differences between what is part
of reference and what is required for Jikes RVM which I think would
lead to preprocessing anyway since I would rather not maintain a
vm/reference and a vm/jikesrvm, but I'd like to hear other ideas as
well.  If preprocessing is unavoidable, then perhaps we'll abandon the
vm/reference directory all together and always use preprocessing.

I'm assuming that John will continue to lead the Jikes RVM support
effort and help keep those bits in sync with other changes as they may
occur.  What is the status of this code you reference, "Additional
code was provided by Maria Butrico. The code she sent me is JRVM
specific code that had been inserted into the IBM OTI class
libraries" ?

Brian
-- 
Brian Jones <address@hidden>