> > 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
