sablevm-developer

[Sablevm-developer] Obsoleting sablevm-classpath NOW!

[Grzegorz B. P. <ga...@de...>]

Hi everybody,

Spoiler: this SableVM supports GNU Classpath CVS out-of-the-box

	svn co svn://svn.sablevm.org/developers/gadek/sandbox/svm-cpootb

[ Instalation instructions are at the end ]

How big hack it is, you'd ask? Well, yes, it is one, but not that big.
But let me explain from the beginning.

==== Story ====

I discussed with Mark integration of GNU CP and SableVM. As far as I
could understand his POV, the course will probably be so that each
VM itself supplied own set of VM* classes. These classes wouldn't need
to reside in GNU CP tree, so ./vm/reference will move to ./vm.
(this is still a matter of discussion, I am not stating what will be!)

Since some time I was looking at the diff between our classpath and
upstream besides changes in VM* classes there were mainly thing related
to ClassLoader, which currently is broken/doesn't exist in GNU CP,
plus some other stuff that will have to be actually merged, ie. removing
static initializers (though not too many of such things).

	So I simply integrated VM* classes subtree with sablevm source,
	plus added these classes, which we have to have modifed because
	of the above reasons. This approach can be seen as
	controversial, but IMO there's no reason for SableVM to suffer
	just because all CP developers (us including) haven't agreed on
	ex. what ClassLoader should look/work like!

The list of "classes that should not be there" (there's currently 12!
of them) is provided and these classes should be eliminated one by one
as soon as Classpath's code of this classes becomes usable for us. But
this can be done incrementally and we can work w/ GNU CP CVS now, and
not at the end of the process.

If this or similar idea gets accepted (are you liestening Etienne? ;-)
we can stop providing our "own" sablevm-classpath tree, but simply
ship (almost) original classpath 'dist' tarball plus sablevm tarball.

Unfortunatelly this doesn't let us forget about merging with GNU CP,
as merging of changes to the VM* classes will always be needed until
the interface isn't stabilized. And of course we need to merge changes
done to these "classes that should not be there" in our tree, but we
do that already anyway and this too should go away after some time.

==== Rough edges ====

The current code has some "features" you should be aware of.
1. Classpath *must* be installed first because jikes needs these
classes to properly compile VM* classes.
2. WARNING: During 'make install' VM* classes from sablevm *overwrite*
Classpath VM* classes (and the "classes that shouldn't be there"
overwrite their counterparts).
3. I assume you're going to use jikes, no other javac is supported ATM.

1. will probably never go away, and 3. don't seem to be very harmful.
Ad. 2: this is because currently bootclasspath can NOT contain more that
one path. This should go away if we add support like for normal
classpath values, so that ":" was used as a separator. Put onto
immediate TODO list *IF* this or similar approach is accepted.

==== Installation instructions ====

1. get SableVM from the above SVN address.
2. get GNU Classpath from CVS http://savannah.gnu.org/cvs/?group_id=85
3. get easy-classpath-build script by using:
svn cat svn://svn.sablevm.org/sablevm-classpath/branches/staging \
 >./build_sablevm-classpath
chmod +x ./build_sablevm-classpath
4. go into GNU Classpath source dir and run 
../svm-cpootb/autogen.sh
../build_sablevm-classpath /where/you/want/to/install
5. go into SableVM source dir 'svm-cpootb'
./autogen.sh && ./configure --prefix=/where/you/want/to/install && \
make && make install

Have fun!

				Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

Re: [Sablevm-developer] Obsoleting sablevm-classpath NOW!

[David <db...@cs...>]

Hello,

I really like this idea!
Good work Grzegorz!

I looked quickly at the reorganization and it looks good.

I will test later, probably wait until it gets into staging.

David

On Sun, Mar 21, 2004 at 09:58:38PM -0500, Grzegorz B. Prokopski wrote:
> Hi everybody,
>=20
> Spoiler: this SableVM supports GNU Classpath CVS out-of-the-box
>=20
> 	svn co svn://svn.sablevm.org/developers/gadek/sandbox/svm-cpootb
>=20
> [ Instalation instructions are at the end ]
>=20
> How big hack it is, you'd ask? Well, yes, it is one, but not that big.
> But let me explain from the beginning.
>=20
> =3D=3D=3D=3D Story =3D=3D=3D=3D
>=20
> I discussed with Mark integration of GNU CP and SableVM. As far as I
> could understand his POV, the course will probably be so that each
> VM itself supplied own set of VM* classes. These classes wouldn't need
> to reside in GNU CP tree, so ./vm/reference will move to ./vm.
> (this is still a matter of discussion, I am not stating what will be!)
>=20
> Since some time I was looking at the diff between our classpath and
> upstream besides changes in VM* classes there were mainly thing related
> to ClassLoader, which currently is broken/doesn't exist in GNU CP,
> plus some other stuff that will have to be actually merged, ie. removin=
g
> static initializers (though not too many of such things).
>=20
> 	So I simply integrated VM* classes subtree with sablevm source,
> 	plus added these classes, which we have to have modifed because
> 	of the above reasons. This approach can be seen as
> 	controversial, but IMO there's no reason for SableVM to suffer
> 	just because all CP developers (us including) haven't agreed on
> 	ex. what ClassLoader should look/work like!
>=20
> The list of "classes that should not be there" (there's currently 12!
> of them) is provided and these classes should be eliminated one by one
> as soon as Classpath's code of this classes becomes usable for us. But
> this can be done incrementally and we can work w/ GNU CP CVS now, and
> not at the end of the process.
>=20
> If this or similar idea gets accepted (are you liestening Etienne? ;-)
> we can stop providing our "own" sablevm-classpath tree, but simply
> ship (almost) original classpath 'dist' tarball plus sablevm tarball.
>=20
> Unfortunatelly this doesn't let us forget about merging with GNU CP,
> as merging of changes to the VM* classes will always be needed until
> the interface isn't stabilized. And of course we need to merge changes
> done to these "classes that should not be there" in our tree, but we
> do that already anyway and this too should go away after some time.
>=20
> =3D=3D=3D=3D Rough edges =3D=3D=3D=3D
>=20
> The current code has some "features" you should be aware of.
> 1. Classpath *must* be installed first because jikes needs these
> classes to properly compile VM* classes.
> 2. WARNING: During 'make install' VM* classes from sablevm *overwrite*
> Classpath VM* classes (and the "classes that shouldn't be there"
> overwrite their counterparts).
> 3. I assume you're going to use jikes, no other javac is supported ATM.
>=20
> 1. will probably never go away, and 3. don't seem to be very harmful.
> Ad. 2: this is because currently bootclasspath can NOT contain more tha=
t
> one path. This should go away if we add support like for normal
> classpath values, so that ":" was used as a separator. Put onto
> immediate TODO list *IF* this or similar approach is accepted.
>=20
> =3D=3D=3D=3D Installation instructions =3D=3D=3D=3D
>=20
> 1. get SableVM from the above SVN address.
> 2. get GNU Classpath from CVS http://savannah.gnu.org/cvs/?group_id=3D8=
5
> 3. get easy-classpath-build script by using:
> svn cat svn://svn.sablevm.org/sablevm-classpath/branches/staging \
>  >./build_sablevm-classpath
> chmod +x ./build_sablevm-classpath
> 4. go into GNU Classpath source dir and run=20
> ../svm-cpootb/autogen.sh
> ../build_sablevm-classpath /where/you/want/to/install
> 5. go into SableVM source dir 'svm-cpootb'
> ./autogen.sh && ./configure --prefix=3D/where/you/want/to/install && \
> make && make install
>=20
> Have fun!
>=20
> 				Grzegorz B. Prokopski
>=20
> --=20
> Grzegorz B. Prokopski <ga...@de...>
> Debian GNU/Linux      http://www.debian.org
> SableVM - LGPLed JVM  http://www.sablevm.org
> Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

--=20

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

Re: [Sablevm-developer] Obsoleting sablevm-classpath NOW!

[Etienne G. <gag...@uq...>]

Grzegorz B. Prokopski wrote:
> Spoiler: this SableVM supports GNU Classpath CVS out-of-the-box

Great!

> These classes wouldn't need
> to reside in GNU CP tree, so ./vm/reference will move to ./vm.
> (this is still a matter of discussion, I am not stating what will be!)

I am far from agreeing with this; this would lead to unnecessary
duplication of code between VM's.  Worse, it would lead to an awkward
installation process.

I definitely think that Classpath should work *out-of-the-box* with all
normal[0] VMs; something like:

$ su
$ tar -xzvf sablevm-x.y.z.tar.gz
$ cd sablevm-x.y.z
$ ./configure
$ make
$ make install
$ cd ..
$ tar -xzvf classpath-x.yy.tar.gz
$ cd classpath-x.yy
$ ./configure
[configure error]: You must specify a vm in the form of the following command
line option --with-vm=[none,sablevm,kaffe,jamvm,jikesrvm,...]
$ ./configure --with-vm=sablevm
$ make
$ make install
$ exit
$ cd ~/hello
$ /usr/local/bin/sablevm HelloWorld
Hello World!
$

This would work best with:
0- All VM-specific code moved to VM*.java classes.
1- VM*.java classes residing in the *normal* Classpath tree.
2- Using m4 to maintain real VM-specific code. [Many VM's
    will probably share "native" method declarations, for example].
3- The /vm subtree could be either eliminated, or kept around for
    unusual[1] VM's.


[0] I mean VM's with a usual build process, such as kaffe, sablevm, etc.
[1] I mean VM's with unusual build process, such as JikesRVM, etc.

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Obsoleting sablevm-classpath NOW!

[Steven A. <au...@wa...>]

Etienne:  Jikes RVM uses a stock classpath build.  All it does is copy 
Classpath's glibj.zip and the .so files over to its own local storage 
place.

We get away with this because we put our own classes earlier in the 
path than Classpath's.  So we always get our own implementation of 
VMRuntime, for instance, and never see Classpath's.  Ditto for all of 
the other VM* classes, I believe.

I'm not sure what improved level of working out-of-the-box you would 
want beyond that.  Perhaps I have misunderstood what you're suggesting?

--Steve Augart


Etienne Gagnon wrote:
> I definitely think that Classpath should work *out-of-the-box* with all
> normal[0] VMs; something like:
[...]
> This would work best with:
> 0- All VM-specific code moved to VM*.java classes.
> 1- VM*.java classes residing in the *normal* Classpath tree.
> 2- Using m4 to maintain real VM-specific code. [Many VM's
>    will probably share "native" method declarations, for example].
> 3- The /vm subtree could be either eliminated, or kept around for
>    unusual[1] VM's.
> 
> 
> [0] I mean VM's with a usual build process, such as kaffe, sablevm, etc.
> [1] I mean VM's with unusual build process, such as JikesRVM, etc.

-- 
Steven Augart

Jikes RVM, open source Research Virtual Machine:
http://oss.software.ibm.com/jikesrvm

Office: +1 914/784-6743
T.J. Watson Research Center, IBM

Re: [Sablevm-developer] Obsoleting sablevm-classpath NOW!

[Etienne G. <gag...@uq...>]

SableVM does not have *any* sablevm-specific class.  It simply uses
the /vm/reference classes with very *minor* modifications (currently
some changes are more than minor simply because it has not yet been
put into upstream classpath; e.g. fills in reflection classes, etc.).

SableVM needs no Java classes of its own.  Also, strictly speaking, a
class outside glibj.zip (which, by the way, should be called libclasspath.jar)
is in a *different* runtime package than any class withing this file,
if one is to follow closely the JVM spec, so the package-private classes
have to live in libclasspath.jar.

Also, I see no reason for SableVM to need to build classpath twice:
- once to build classpath itself, and
- once to re-build the VM*.java classes just for sablevm to be able
   to put those classes in an awkward place on the system...

I really do not see various VMs sharing the same Classpath installation;
ther would be just too much possible problems.

So, to answer your question: out-of-the-box means:
1- A user downloads SableCC (written in C) and compiles it (needs gcc).
2- Same user downloads Classpath (written in C and Java), and compiles it
    (needs gcc and jikes).
3- User runs Java software. :-)

No hacks, no special classes in special directories, no ugly things.  It
just plainly works with (eventually) a single .jar file (+ .so files).
[Currently needs classes in directory tree.  Zlib patch pending commit
in SableVM tree...]


Etienne

Steven Augart wrote:
> Etienne:  Jikes RVM uses a stock classpath build.  All it does is copy 
> Classpath's glibj.zip and the .so files over to its own local storage 
> place.
> 
> We get away with this because we put our own classes earlier in the path 
> than Classpath's.  So we always get our own implementation of VMRuntime, 
> for instance, and never see Classpath's.  Ditto for all of the other VM* 
> classes, I believe.
> 
> I'm not sure what improved level of working out-of-the-box you would 
> want beyond that.  Perhaps I have misunderstood what you're suggesting?
> 
> --Steve Augart

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/