Re: GNU Classpath + JRVM

[John Leuner]

> > http://people.debian.org/~jewel//jikes/port_poc.html
> > http://people.debian.org/~jewel//jikes/futurechanges.html
> 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?

Yes, that would work.
 
> 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?

I don't remember any specific reason for commenting them out.

There are/were one or two cases where I had to 'fabricate' a static initializer
for a class, but I think that is unrelated to the commenting of the 
INIT_LOAD_LIBRARY
 blocks.

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

I don't know, in my notes I didn't write down a reason.

I removed the field, recompiled and it ran successfully.

This was probably a side-effect of including the GNU libraries piece by piece.

> 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 don't like preprocessing because it implies another level in the build 
process, 
but it looks like the best option at the moment.

Classpath is still changing a lot, I think it will be easier for developers to 
see what effect their changes will have when all the code is in the same place
(versus in separate VM files).

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

Sure 

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

This is essentially the code that calls methods in the VM_* classes.

It doesn't really have a "home" .. it was extracted from the changes made 
to the IBM OTI libraries. There may be a few cases where we can reduce
the amount of extra code needed in Classpath by including code upstream in JRVM.

John Leuner