As part of the systematic change from int to VM_Address, I had to modify
the jni test TestGC.java to use VM_Address instead of int. However, the
JDK test now fails because VM_Address is a class that the JDK cannot find.
However, TestGC.java also has a reference to class VM and it had no trouble
finding that before. Can someone tell me what's going on here?
Perry

I have updated my page with details on the port of GNU Classpath:
http://people.debian.org/~jewel/jikes/jikesport/
This now contains two scripts which will download the Classpath CVS and patch the JRVM as necessary for you to build a working executable.
John Leuner
On Fri, Mar 22, 2002 at 07:20:12PM +0000, John Leuner wrote:
> I have written a description containing the twenty steps needed to compile and run JRVM 2.02 with GNU Classpath:
>
> http://people.debian.org/~jewel/jikes/STEPS
>
> And associated files:
>
> http://people.debian.org/~jewel/jikes/jikes-cp.tar.gz
> http://people.debian.org/~jewel/jikes/jbuild.linkImage.patch
>
> There is more work to be done on this. I should break the JRVM diffs down into
> two patches. There are changes there that should be included in the JRVM source,
> perhaps with a conditional which can be specified in the relevant rvm/config/<file>.
>
> I have to update this to work with the latest code in Classpath CVS, as well as with JRVM 2.03.
>
> This is still pretty much untested, I would like to have a look at the regression tests and mauve later.
>
> John Leuner
>
> On Thu, Mar 21, 2002 at 10:50:40AM -0500, Julian Dolby wrote:
> >
> > Some objects are created during boot image writing, and are subsequently
> > used when Jikes RVM is running; the opt. compiler has several such data
> > structures. These objects must be allocated at boot image writing time by
> > the JDK and written into the boot image to be read by RVM. This requires
> > that the format of the object created by the JDK (i.e. fields, static data)
> > be somewhat similar to that expected at runtime by Jikes RVM.
> >
> > Since the libraries we currently use are not based on Sun code, this is
> > not the case for several of the java.util classes. The purpose of libyuck
> > is to force the boot image writer to use the java.util classes Jikes RVM
> > expects rather than those it normally uses. It does this by putting
> > libyuck at the front of the bootstrap class path of the JDK. This is
> > fragile because the JDK seems to have some built in assumptions about some
> > java.util classes, but it works for the set of classes in there now.
> >
> > I would expect that the CLASSPATH libraries will have similar issues.
> > You will likely need to put some set of CLASSPATH classes into libyuck.jar
> > to force the JDK to use them when writing boot image objects.
> >
> > You should probably start by not putting anything into libyuck.jar, and
> > see where problems arise during boot image writing. For classes that
> > cannot be written into the boot image correctly, try putting them into
> > libyuck.
> >
> > -- Julian
> >
> >
> > _______________________________________________
> > Jikesrvm-core mailing list
> > Jikesrvm-core@...
> > http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-core
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-core

I have written a description containing the twenty steps needed to compile and run JRVM 2.02 with GNU Classpath:
http://people.debian.org/~jewel/jikes/STEPS
And associated files:
http://people.debian.org/~jewel/jikes/jikes-cp.tar.gzhttp://people.debian.org/~jewel/jikes/jbuild.linkImage.patch
There is more work to be done on this. I should break the JRVM diffs down into
two patches. There are changes there that should be included in the JRVM source,
perhaps with a conditional which can be specified in the relevant rvm/config/<file>.
I have to update this to work with the latest code in Classpath CVS, as well as with JRVM 2.03.
This is still pretty much untested, I would like to have a look at the regression tests and mauve later.
John Leuner
On Thu, Mar 21, 2002 at 10:50:40AM -0500, Julian Dolby wrote:
>
> Some objects are created during boot image writing, and are subsequently
> used when Jikes RVM is running; the opt. compiler has several such data
> structures. These objects must be allocated at boot image writing time by
> the JDK and written into the boot image to be read by RVM. This requires
> that the format of the object created by the JDK (i.e. fields, static data)
> be somewhat similar to that expected at runtime by Jikes RVM.
>
> Since the libraries we currently use are not based on Sun code, this is
> not the case for several of the java.util classes. The purpose of libyuck
> is to force the boot image writer to use the java.util classes Jikes RVM
> expects rather than those it normally uses. It does this by putting
> libyuck at the front of the bootstrap class path of the JDK. This is
> fragile because the JDK seems to have some built in assumptions about some
> java.util classes, but it works for the set of classes in there now.
>
> I would expect that the CLASSPATH libraries will have similar issues.
> You will likely need to put some set of CLASSPATH classes into libyuck.jar
> to force the JDK to use them when writing boot image objects.
>
> You should probably start by not putting anything into libyuck.jar, and
> see where problems arise during boot image writing. For classes that
> cannot be written into the boot image correctly, try putting them into
> libyuck.
>
> -- Julian
>
>
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-core

Some objects are created during boot image writing, and are subsequently
used when Jikes RVM is running; the opt. compiler has several such data
structures. These objects must be allocated at boot image writing time by
the JDK and written into the boot image to be read by RVM. This requires
that the format of the object created by the JDK (i.e. fields, static data)
be somewhat similar to that expected at runtime by Jikes RVM.
Since the libraries we currently use are not based on Sun code, this is
not the case for several of the java.util classes. The purpose of libyuck
is to force the boot image writer to use the java.util classes Jikes RVM
expects rather than those it normally uses. It does this by putting
libyuck at the front of the bootstrap class path of the JDK. This is
fragile because the JDK seems to have some built in assumptions about some
java.util classes, but it works for the set of classes in there now.
I would expect that the CLASSPATH libraries will have similar issues.
You will likely need to put some set of CLASSPATH classes into libyuck.jar
to force the JDK to use them when writing boot image objects.
You should probably start by not putting anything into libyuck.jar, and
see where problems arise during boot image writing. For classes that
cannot be written into the boot image correctly, try putting them into
libyuck.
-- Julian

What is the purpose of libyuck.jar?
I see it has the following files:
java/util/zip/ZipConstants.class
java/util/HashMap$1.class
java/util/HashMap$2.class
java/util/HashMap$3.class
java/util/HashMap$HashEntry.class
java/util/HashMap$HashIterator.class
java/util/HashMap.class
java/util/HashSet.class
java/util/Map$Entry.class
java/util/Map.class
The bootImageWriter has the following comment:
#
# The -Xbootclasspath/p:$(UTIL_KLUDGE_JAR) is a kludge to force
# the hosting jvm to use the same java.util files that the rvm will use
# at run time. This mechanism is very fragile and only works for a
# subset of java.util classes (discovered by trial and error).
#
Why is this necessary? What is the implication for using GNU Classpath (the names of the Hash{Map/Set/table} classes are different)?
John Leuner

> Now that I've completed this 'proof of concept', I would like to generate a document or plan for a more thorough port.
>
> Next week I hope to identify areas where I have changed JRVM and Classpath and talk about how we can make less of these changes necessary.
I have written a document at:
http://people.debian.org/~jewel//jikes/port_poc.html
Currently it is mostly just a summary for myself.
Tomorrow I will start asking questions about how to proceed with future work.
John Leuner

We'd like to release 2.0.3 fairly soon. Any objections to releasing it
tomorrow morning if no new failures show up tonight?
SJF
------------------------------------------------------------------------
Stephen Fink
IBM T.J. Watson Research Center
sjfink@...
(914)784-7776