sablevm-developer

[Sablevm-developer] trying SableVM in Debian

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

Hi!

There has been RFP (Request for packaging) filled on SableVM.
I have not yet decided to get on it, to create and maintain SableVM
in Debian - I'd like to try it first. And I have a couple of questions.
Please Cc: me as I am not subscribed to the list.

1. I fetched all three source tarballs.
sablevm and sablevm-native-library compiled w/o problems but
how am I supposed to compile sablevm-class-library when there's
no autogen/configure/Makefile in it?
I think I _could_ copy them from original classlib sources, but
it ain't right soulution. Is this an oversight or are there reasons
for not including any build machinery into this source tarball?

2. More general. I looked at changelog and TODO list to get some
impression in what state SableVM is ATM. However I'd like to ask
you few simple question.
- can I use jar files w/o problems (it was mentioned in changelog
as done, but in TODO list there was sth. about zip files not being
supported and jars treated as zips - so finally not sure here)
- what classpath integration pieces are missing?=20
Can I use their gtk-peers? What will those missing pieces impact?
- do you see yourself as research mainly project? I mean - do you
want your JVM to be developed and used seriously or...
- Currently we seem to have a lot free JVMs available. Why is your
so different? better than the others? - so you decided to hack on
that one not on them?
- how would you compare your JVM with classpath duo to what kaffe
is (technically)? Do you have any (more-less accurate) benchmarks?
Can you run all the apps that kaffe can run? more? less?
Where are the problems? When will they probably be solved?

I'd like to know what you can say about the above. If I decide to
carry on maintaining SableVM - I'd like to know what I am putting
myself into.

From practical POV - we (in Debian) don't really need tenth JVM that
works just like all the other. So far it seems that you're better
because of:
1. no licensing problems (kaffe and it's libs are GPL)
2. support for jars (strange, but some other free JVMs need to have
classes unpacked first - which is hardly acceptable)
3. integration with classpath (java 1.2, a bit more than kaffe has)

Thank you for all your answers and thoughts. Please Cc: me.

Best regards

					Grzegorz B. Prokopski

Re: [Sablevm-developer] trying SableVM in Debian

[Etienne M. G. <eti...@uq...>]

Hi Grzegorz,

Grzegorz Prokopski wrote:
> 1. I fetched all three source tarballs.
> sablevm and sablevm-native-library compiled w/o problems but
> how am I supposed to compile sablevm-class-library when there's
> no autogen/configure/Makefile in it?
> I think I _could_ copy them from original classlib sources, but
> it ain't right soulution. Is this an oversight or are there reasons
> for not including any build machinery into this source tarball?


There is a README file in the sablevm-1.0.1.tar.gz files as well as a convenient 
"build" script which you could inspect, if you want to cutomize destination 
directories (which is probably the case).

Mainly, you compile the classes using a bash script which looks like:

tar -xzf sablevm-class-library-$VERSION.tar.gz
cd sablevm-class-library-$VERSION
mkdir classes
find | grep \\.java$ | xargs jikes -g -d classes \
  -bootclasspath src:classes -classpath src:classes -sourcepath src
find resource -type f | cut -d\/ -f2- | \
  awk '{print "cp resource/" $0 " classes/" $0 }' | sh
chmod -R a+rX classes
rm -rf $LOCATION/lib/sablevm/classes-$VERSION
mv classes $LOCATION/lib/sablevm/classes-$VERSION
cd ..

> 2. More general. I looked at changelog and TODO list to get some
> impression in what state SableVM is ATM. However I'd like to ask
> you few simple question.

The TODO is GNU Classpath's todo.  Do not confuse Classpath and SableVM. No, I 
have NOT included a TODO file with SableVM.

I have been able to run all the SPECjvm98 benchmarks, including the 
multi-threaded ones, very reliably.  I have also been able to run things like 
"SableCC 2.17.3" to generate a parser for the (huge) java grammar (this is 
something I have yet to see Orp, Kaffe, Kissme, Japhar or any other do).  Even 
better, I have been able to run Soot 1.2.3, which even breaks some of IBM's 
flagship JITs.

Of course, I have not tested SableVM with all possible applications, and it has 
its shortcomings.  For example, it cannot run the stable version of SableVM 
(2.16.2), because of incomplete implementation or Serialization in Classpath (or 
bugs in Classpath?).  And even if Classpath was fixed, there might yet be some 
missing support in SableVM.  I think it would need to implement things like 
Field.getModifiers() [which is fairly simple to implement, maybe 5 lines of code?].

SableVM supports class loaders; in fact all "application" classes are loaded 
through a Java written Class loader.  So, you can type things like (assuming 
sablecc-2.17.3):

sablevm --classpath sablevm.jar:java-getopt.jar org.sablecc.sablecc.SableCC

> - can I use jar files w/o problems (it was mentioned in changelog
> as done, but in TODO list there was sth. about zip files not being
> supported and jars treated as zips - so finally not sure here)

See example above.  Now, SableVM does not yet support writing:

sablevm -jar executable.jar

But, this should be fairly simple to implement.  I won't personally do it now, 
as I am writing my Thesis. But, if no contributor does it within the next month, 
I'll probably do it then.

> - what classpath integration pieces are missing? 
> Can I use their gtk-peers? What will those missing pieces impact?

There's so much a single person can do... Why don't you try it by yourself and 
tell me what's missing, so that I (or others) fix it?

> - do you see yourself as research mainly project? I mean - do you
> want your JVM to be developed and used seriously or...

I want the JVM to be developed and used seriously.  Now, it is an INTERPRETER, 
not a JIT (but there are already projects to eventually add a JIT).  The idea is 
that it is an efficient and portable interpreter.  Depending on the application, 
it can compare sometimes favorably to Sun's "Java -Xint".  This is an order of 
magnitude faster than Kaffe's interpreter (and most other interpreters).  With 
the big difference that SableVM is written in portable ISO C (with optional GNU 
extentions for direct/inlined threading), and only assumes a POSIX system library.

The implementation of JNI and the Invoke interface, does the right things around 
native calls.  The "precise" garbage collector doesn't fail in presence of 
complex jsr/exception mixes. etc.

This was the whole point behind writing an interpreter: to have time to make it 
robust, and as complete as possible.

Now, of course, it is ALSO meant as a research vehicle.  But the idea is to 
allow doing research with a VM that is able to run real-world applications, not 
only bechmarks.

The SableVM will remain entirely dependent on the GNU Classpath project, for its 
class libraries.  Implementing a robust VM is already enough work for an 
academic research team!  So, as long as Classpath won't have solid AWT support, 
SableVM will lack in that department, etc.

> - Currently we seem to have a lot free JVMs available. Why is your
> so different? better than the others? - so you decided to hack on
> that one not on them?

Robustness.  Off the top of my head... I wanted a VM that would have:
1- A clean implementation of JNI and the Invoke interface. Did you know that 
SableVM allows for more than one VM in a single process, living or distinct 
threads, of course?
2- Innovative memory management.
3- Low learning curve for new developers.
4- Allows for easily adding new kinds of bytecode instructions (for reasearching 
things like VM support for parametric types).
5- Was built with both portability AND efficiency in mind.  JITs are efficient, 
but not portable. Most interpreters are (sometime) portable and (most of the 
time) very, very slow, unless parts are coded in assembly.  (Even if the 
JikesRVM is written in Java, it is not easily portable; targetting a new 
platforms involves modifying 3 optimizing compilers!)
6- More...  Read the paper referenced on the SableVM web page.  It has a fairly 
good motivation section which should be simple to read.

> - how would you compare your JVM with classpath duo to what kaffe
> is (technically)? Do you have any (more-less accurate) benchmarks?

Kaffe is GPL'ed without exception.  So you might be introuble for running 
proprietary applications, if you strictly follow the license.

On the benchmark side, I have yet to see Kaffe run all of the SPECjvm98 
benchmarks, SableCC and Soot.

> Can you run all the apps that kaffe can run? more? less?
> Where are the problems? When will they probably be solved?

You tell me.

> I'd like to know what you can say about the above. If I decide to
> carry on maintaining SableVM - I'd like to know what I am putting
> myself into.

You might also want to discuss with Brent Fulgham (another Debian developer). I 
think he was also interested in packaging SableVM.  But, sometimes he takes a 
while to read his mail...

>>From practical POV - we (in Debian) don't really need tenth JVM that
> works just like all the other. So far it seems that you're better
> because of:
> 1. no licensing problems (kaffe and it's libs are GPL)
> 2. support for jars (strange, but some other free JVMs need to have
> classes unpacked first - which is hardly acceptable)

Most other free VM's have big shortcomings in the areas of ClassLoaders and 
applying the correct Class Initialization procedures.  It's far from easy to get 
right.  Also, getting precise garbage collection (instead of plugging a 
conservative collector) in absence of verifier is quite tricky (as I explain in 
my thesis).  At first sight, Orp seems to have got this one wrong.

I repeat: SableVM was built with robustness in mind.

> 3. integration with classpath (java 1.2, a bit more than kaffe has)
> 
> Thank you for all your answers and thoughts. Please Cc: me.
> 

I won't have much time to debate this further.  I have, unfortunately, a thesis 
to finish writing.  Experiment with SableVM, look at its source code, if you are 
litterate in C, and I'm pretty sure you'll like it.  I encourage you to also 
look at the source code of other free VM's and notice the differences in the 
approach.

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

Re: [Sablevm-developer] trying SableVM in Debian

[Etienne M. G. <eti...@uq...>]

Etienne M. Gagnon wrote:
> =B7=B7=B7   For example, it cannot run the stable version
> of SableVM (2.16.2),=20

I meant SableCC, of course.

Have fun!

Etienne
--=20
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] trying SableVM in Debian

[Etienne M. G. <eti...@uq...>]

Etienne M. Gagnon wrote:
> On the benchmark side, I have yet to see Kaffe run all of the SPECjvm98 
> benchmarks, SableCC and Soot.

To be honest, my current experiments show that the latest verions of Kaffe has 
been fixed to run all of SPECjvm98.  I'm still trying to get SableCC and Soot to 
run on it, though.

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

Re: [Sablevm-developer] trying SableVM in Debian

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

W li=B6cie z nie, 11-08-2002, godz. 02:43, Etienne M. Gagnon pisze:=20
> Etienne M. Gagnon wrote:
> > On the benchmark side, I have yet to see Kaffe run all of the SPECjvm98=
=20
> > benchmarks, SableCC and Soot.
>=20
> To be honest, my current experiments show that the latest verions of Kaff=
e has=20
> been fixed to run all of SPECjvm98.  I'm still trying to get SableCC and =
Soot to=20
> run on it, though.
Yes, kaffe 1.0.7 is MAJOR step forward.
The number change 1.0.6->1.0.7 doesn't show how much effort was put
into it since previous release.

Oh - and it is being ported to all Debian architectures (just released
Woody has 11 of them).

While we're at it - what's the status of ports of SableVM?
From what I could read using that ugly SF archive - it works on i386
and Alpha. Any others? Are there plans/people working on new ones?

Regards

					Grzegorz B. Prokopski

PS: I _am_ subscribed to -dev list now - you don't _need_ to Cc: me (but
you may as it makes no difference at all for me)

Re: [Sablevm-developer] trying SableVM in Debian

[Etienne M. G. <eti...@uq...>]

On Sun, Aug 11, 2002 at 11:48:30AM +0200, Grzegorz Prokopski wrote:
> W li?cie z nie, 11-08-2002, godz. 02:43, Etienne M. Gagnon pisze: 
> > Etienne M. Gagnon wrote:
> > > On the benchmark side, I have yet to see Kaffe run all of the SPECjvm98 
> > > benchmarks, SableCC and Soot.
> > 
> > To be honest, my current experiments show that the latest verions of Kaffe has 
> > been fixed to run all of SPECjvm98.  I'm still trying to get SableCC and Soot to 
> > run on it, though.
> Yes, kaffe 1.0.7 is MAJOR step forward.
> The number change 1.0.6->1.0.7 doesn't show how much effort was put
> into it since previous release.
> 
> Oh - and it is being ported to all Debian architectures (just released
> Woody has 11 of them).
> 
> While we're at it - what's the status of ports of SableVM?
> >From what I could read using that ugly SF archive - it works on i386
> and Alpha. Any others? Are there plans/people working on new ones?

I have personally only built it on x86.  The code of SableVM (I can't
speak for Classpath) has been desinged to work, with minimal changes
in 3 files, to any POSIX platform very easily. The only caveat: On
multi-processors, SableVM assumes a strong memory model (i.e. cache
coherency).  Weak memory models are not supported, but this shouldn't
be a big limitation, as currently, the JVM specification is broken in
this regard.

I will let users take care of porting to different architectures, as I
do not have the machines to test other architectures.  In the fall, I
will have Sun machines, so I'll port it there at that point.

Etienne


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