sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] regression testing staging@r1575 and sablevm-classpath@r1575 against 1.0.9

[Mark W. <ma...@kl...>]

Hi,

On Fri, 2004-02-13 at 06:21, Grzegorz B. Prokopski wrote:
> W li=B6cie z czw, 12-02-2004, godz. 23:04, Chris Pickett pisze:=20
> > 2) A fix for the classpath configure problem (I think the easiest is to=
=20
> > undo Mark's configure.ac patch, since apparently this was only for JamV=
M).
> I guess we can just undo the change for this moment, but it'd be
> best to ask on gnu classpath ML. Hmmm... I think he's on SableVM list.
>=20
> Mark? :-)

Something like that patch is definitely needed. Not just for JamVM,
libgcj needed the same to be able to run AWT programs, see:
http://gcc.gnu.org/ml/java-patches/2004-q1/msg00411.html

Is pkg.m4 available on the machine, in sablevm?
Seems the problem is that the PKG_CHECK_MODULES macro from that file
isn't defined. On a debian system it comes from the package
'pkg-config'.

Cheers,

Mark

Re: [Sablevm-developer] regression testing staging@r1575 and sablevm-classpath@r1575 against 1.0.9

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

W li=B6cie z czw, 12-02-2004, godz. 23:04, Chris Pickett pisze:=20
> You can see the results of the benchmark runs in:
>=20
> http://sable.mcgill.ca/~cpicke/sablevm/r1575-vs-1.0.9/

Great! I've just looked at them, see below.

> *_times_* are the raw benchmark times
> *_report_* are reports, with user times and pass/fail status (see first=
)
> *_diff_* are diffs that caused failure in the reports
> *_paranoid_diff_* are diffs that don't ignore run-specific information
>=20
> Basically:
>=20
> 1) I found no regressions
I have to believe you, because I looked at the diffs and firstly:

I don't know what I am comaring with what. I mean, that you used
just diff, instead of ex. 'diff -u', which would put filenames
into the header.

Second thing, partially being result of the first one: I looked at
http://www.sable.mcgill.ca/~cpicke/sablevm/r1575-vs-1.0.9/grande_section1=
_diff_feb12
and it seems that errors are not identical. I guess that both cases
qualify as "doesn't work", but still - I'd love to know which errors
do we get now. Do I get it right, that w/ 1.0.9 we get link error,
and now we get security provider error (so it's more CP problem)?

> 2) mtrt seems to have been fixed for switch-debug (no blank line)
oh, and how about switch w/o signals? It might be interesting to see.

> 3) JGFSyncBench, JGFLUFactBench, and JGFRayTracerBench fail
>       (single- and multi-threaded errors)
> 4) JGFSerialBench fails, but it fails for java as well
>       (verification error)
> 5) In general things are faster, but there are a couple of exceptions.
Working on it. Inlined is staging is ATM not reliable in terms of speed.
There are good chances to get fixed this weekend.

> 1) A list of known issues (incl. the above benchmark failures and the=20
> fact that synchronized methods may crash the VM)
> 2) A fix for the classpath configure problem (I think the easiest is to=
=20
> undo Mark's configure.ac patch, since apparently this was only for JamV=
M).
I guess we can just undo the change for this moment, but it'd be
best to ask on gnu classpath ML. Hmmm... I think he's on SableVM list.

Mark? :-)

I think Chirs, that you've just pushed 1.1.0 a lot to make it reality.
Thanks a lot!

Cheers,

					Grzegorz B. Prokopski

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

Re: [Sablevm-developer] regression testing staging@r1575 and sablevm-classpath@r1575 against 1.0.9

[Chris P. <chr...@ma...>]

Chris Pickett wrote:

> Grzegorz B. Prokopski wrote:
>=20
>> W li=B6cie z czw, 12-02-2004, godz. 13:56, Chris Pickett pisze:
>>
>>> I updated sablevm-classpath, but now I can't run configure anymore,=20
>>> even with --no-gtk specified.
>>>
>>> ./configure: line 21672: syntax error near unexpected token=20
>>> `PKG_CHECK_MODULES(GTHREAD,'
>>> ./configure: line 21672: `     PKG_CHECK_MODULES(GTHREAD, gthread-2.0=
=20
>>> >=3D 2.2)'
>>
>>
>>
>> I haven't seen these problems, at least last weekend, and I don't thin=
k
>> much has been changed since then. Try these:
>>
>> aclocal-1.7 && libtoolize --force && autoconf && autoheader &&
>> automake-1.7 --foreign -a -c
>>
>> If you use Debian, and have the right versions of the tools installed
>> - the above programs should be found.
>>
>=20
> So, it compiled.  But I couldn't get it to work without dnl'ing the=20
> lines in question (I tried the above commands).  It needs to be fixed=20
> before moving into bugfree, IMHO, but I don't know how.  Feel free to=20
> verify it on one of the Sable machines with the versions I have=20
> (aclocal-1.8.2, libtoolize-1.5.2, autoconf-2.59, autoheader-2.59,=20
> automake-1.8.2, which are the latest versions -- I just installed them)=
=2E
>=20
> You can see the results of the benchmark runs in:
>=20
> http://sable.mcgill.ca/~cpicke/sablevm/r1575-vs-1.0.9/

Sorry.  I never seem to get url's right :/

http://www.sable.mcgill.ca/~cpicke/sablevm/r1575-vs-1.0.9/

Chris

Re: [Sablevm-developer] regression testing staging@r1575 and sablevm-classpath@r1575 against 1.0.9

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

> W li=B6cie z czw, 12-02-2004, godz. 13:56, Chris Pickett pisze:=20
>=20
>>I updated sablevm-classpath, but now I can't run configure anymore, eve=
n=20
>>with --no-gtk specified.
>>
>>./configure: line 21672: syntax error near unexpected token=20
>>`PKG_CHECK_MODULES(GTHREAD,'
>>./configure: line 21672: `     PKG_CHECK_MODULES(GTHREAD, gthread-2.0 >=
=3D=20
>>2.2)'
>=20
>=20
> I haven't seen these problems, at least last weekend, and I don't think=

> much has been changed since then. Try these:
>=20
> aclocal-1.7 && libtoolize --force && autoconf && autoheader &&
> automake-1.7 --foreign -a -c
>=20
> If you use Debian, and have the right versions of the tools installed
> - the above programs should be found.
>=20

So, it compiled.  But I couldn't get it to work without dnl'ing the=20
lines in question (I tried the above commands).  It needs to be fixed=20
before moving into bugfree, IMHO, but I don't know how.  Feel free to=20
verify it on one of the Sable machines with the versions I have=20
(aclocal-1.8.2, libtoolize-1.5.2, autoconf-2.59, autoheader-2.59,=20
automake-1.8.2, which are the latest versions -- I just installed them).

You can see the results of the benchmark runs in:

http://sable.mcgill.ca/~cpicke/sablevm/r1575-vs-1.0.9/

*_times_* are the raw benchmark times
*_report_* are reports, with user times and pass/fail status (see first)
*_diff_* are diffs that caused failure in the reports
*_paranoid_diff_* are diffs that don't ignore run-specific information

Basically:

1) I found no regressions
2) mtrt seems to have been fixed for switch-debug (no blank line)
3) JGFSyncBench, JGFLUFactBench, and JGFRayTracerBench fail
      (single- and multi-threaded errors)
4) JGFSerialBench fails, but it fails for java as well
      (verification error)
5) In general things are faster, but there are a couple of exceptions.

*** I didn't run the SizeB and SizeC benchmarks from JGF, since they=20
take too long ***

This is what I think is needed for bugfree:

1) A list of known issues (incl. the above benchmark failures and the=20
fact that synchronized methods may crash the VM)
2) A fix for the classpath configure problem (I think the easiest is to=20
undo Mark's configure.ac patch, since apparently this was only for JamVM)=
=2E

Cheers,
Chris

[Sablevm-developer] Re: SableVM/Solaris status report request

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

On Sun, Feb 08, 2004 at 11:35:23AM -0500, David B=E9langer wrote:
> On Sun, Feb 08, 2004 at 02:48:46AM -0500, Grzegorz B. Prokopski wrote:
> > Hi guys!
> >=20
>=20
> Hi Greg,
>=20
> > AFAIK there were some problems w/ Solaris port of SableVM, like:
> > - you had to fix libffi,
>=20
> yes.

Hi,

Small update for Solaris/sparc.

libffi - Tried again with snapshot extracted from pyobjc project.
         Not working, looks syntax errors in assembly file.
Will study/fix that later.

> > - in classpath you changed file longint to standard int (which
> > would suggest that 64-bit value handling was broken?)
>=20
> I remember at the beginning we had to change a few 64-bit int
> to 32-bit int.  But these should be no longer necessary.
>=20

Classpath/staging almost works for Solaris/sparc.
2 issues:
- need extra include for a #define constants.
- does not compile doc
See patch attached.

> > Have the libffi fixes for Solaris been pushed upstream?
> > Where's the diff of them?
> >=20
>=20
> If I remember well for libffi, we took and maybe modified part of the
> newer version into an older version.  We will need to have a look again
> at that with a recent libffi and send the diff upstream.
>=20

Will look into that later.

>=20
> > Have the problem w/ 64-bit values been fixed?
> >=20
>=20
> Yes.
>=20

SableVM bootstraps and runs HelloWorld kind of programs.  Did not
heavily test.  64-bit problem seems ok with old modified libffi.

No changes are required in SableVM.

Did not run the BTS yet.

Help for SableVM/Solaris welcome.


David

---

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] regression testing staging@r1575 and sablevm-classpath@r1575 against 1.0.9

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

W li=B6cie z czw, 12-02-2004, godz. 13:56, Chris Pickett pisze:=20
> I updated sablevm-classpath, but now I can't run configure anymore, eve=
n=20
> with --no-gtk specified.
>=20
> ./configure: line 21672: syntax error near unexpected token=20
> `PKG_CHECK_MODULES(GTHREAD,'
> ./configure: line 21672: `     PKG_CHECK_MODULES(GTHREAD, gthread-2.0 >=
=3D=20
> 2.2)'

I haven't seen these problems, at least last weekend, and I don't think
much has been changed since then. Try these:

aclocal-1.7 && libtoolize --force && autoconf && autoheader &&
automake-1.7 --foreign -a -c

If you use Debian, and have the right versions of the tools installed
- the above programs should be found.

HTH

					GBP

PS: I looked at the patch you pointed out and it seems to be fine.

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

[Sablevm-developer] regression testing staging@r1575 and sablevm-classpath@r1575 against 1.0.9

[Chris P. <chr...@ma...>]

Hi,

I'm trying to do regression tests of staging and sablevm-classpath at 
r1575 against 1.0.9.  I'll run SPECjvm98, JOlden, and JGF single- and 
multi-threaded.  If you commit things after 1575 besides scripts and 
documentation, they won't get regression-tested by me.  Greg wants to 
move to bugfree if the regression tests are fine.

I updated sablevm-classpath, but now I can't run configure anymore, even 
with --no-gtk specified.

./configure: line 21672: syntax error near unexpected token 
`PKG_CHECK_MODULES(GTHREAD,'
./configure: line 21672: `     PKG_CHECK_MODULES(GTHREAD, gthread-2.0 >= 
2.2)'

The mail about this is here:

http://mail.gnu.org/archive/html/commit-classpath/2004-02/msg00001.html

I have libtool-1.5.2, automake-1.8.2, and autoconf-2.59 ...

I can take out this code for now to compile things.

Chris

[Sablevm-developer] Bug#230770: /usr/bin/java-sablevm: Same bug also on alpha architecture

[Andrew M. <an...@ma...>]

Package: sablevm
Version: 1.0.9-3
Severity: normal
File: /usr/bin/java-sablevm
Followup-For: Bug #230770


Hello, 

I just would like to add, that I have the same problem for alpha
architecture.

This is what I am doing:


$  java -v HelloJava
[verbose jni: JNI_CreateJavaVM]
[verbose gc: allocating initial heap (16777216 bytes)]
[verbose class: loading "java/lang/Object"]
sablevm: cannot create vm



Thanks for listening,

	Andrew


-- System Information:
Debian Release: testing/unstable
Architecture: alpha
Kernel: Linux scrat 2.4.24.am #1 Fri Jan 9 11:05:51 CET 2004 alpha
Locale: LANG=C, LC_CTYPE=C

Versions of packages sablevm depends on:
ii  java-common                 0.22         Base of all Java packages
ii  libc6.1                     2.3.2.ds1-11 GNU C Library: Shared libraries an
ii  libffi2                     1:3.3.2-4    Foreign Function Interface library
ii  libltdl3                    1.5-8        A system independent dlopen wrappe
ii  libpopt0                    1.7-4        lib for parsing cmdline parameters
ii  libsablevm1                 1.0.9-3      Free implementation of JVM second 
ii  unzip                       5.50-3       De-archiver for .zip files

-- no debconf information

Re: [Sablevm-developer] Extending SableVM with static stack caching

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

Hi Heinrich,

Heinrich Moser wrote:
> As my master's thesis (I'm a computer science student) I want to
> evaluate static stack caching. That's an interpreter technique where
> you keep the top n stack items in registers to minimize the amount of
> necessary memory move operations.
> 
> So what I'm planning to do is to take an existing JVM, run some
> benchmarks, implement static stack caching (e.g. using vmgen), run the
> benchmarks again and evaluate the results.
> 
> Therefore, I need a JVM that's (a) stable enough to run the benchmarks
> and (b) has clean code so that it is easy to extend. As far as I can
> tell from what I've read online, SableVM would be a good choice.
> 
> Now I thought I'd ask you a few questions before proceeding:
> 
> * What version should I use?

Currently: The "staging" version.  It's the best one available for the moment.
Soon, Greg (Grzegorz) and David will release a "bugfree" version which would
also be an interesting candidate.

Ideally, whichever version you pick, you should be working within a
Subversion working copy, so that you can easily extract "patches" against
a "precise" version, e.g.

$ svn info
....  // precide info about what you were working against
$ svn diff
... // "unified diff" of your changes against the code in the Subversion repository

> * Did someone already try some benchmarks on SableVM?

Look in my Ph.D. thesis for some performance numbers.  Others (Greg, David, Chris...)
might have additional information.  (BTF, AshesX, ... ???)

> * Any other comments or suggestions?

Just that you are very welcome to use SableVM and comment back about any improvement
you would suggest.

> Some other comments:
> 
> * "Stable" (as mentioned on <http://www.sablevm.org/getit.html>)
>   doesn't seem to be available -- at least I couldn't find a link to
>   it anywhere.

This is intentional, as the latest stable version uses a much too old
GNU Classpath snapshot.

> * The Wiki cannot be edited with IE or Opera. The reason is the
>   <plaintext> tag that's used to display the LGPL. <plaintext> cannot
>   be turned off (see RFC 1866: there is no </plaintext>) and is highly
>   deprecated.

I'll leave this to Greg, our web/admin master.

> * Although <http://devel.sablevm.org/docs/INSTALL.txt> claims that
>   only libart-dev is required for SABLEVM-CLASSPATH, you (also?) need
>   libart-2.0-dev to configure successfully.


I'll let Greg investigate this, too. :-)

> * I didn't really test it in-depth but SableVM seems to run well on my
>   testing system (user-mode-linux on i386 with Debian sarge/testing).

Super.

Have fun!

Etienne

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

[Sablevm-developer] Re: sablevm-classpath broken??

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

On Tue, Feb 10, 2004 at 05:29:38PM -0500, Etienne Gagnon wrote:
> Weird...
>=20
> I have redone it, changing two things:
> 1- in the target location, I changed the name from .../sablevm-inlined =
to=20
> .../sablevminl
> 2- I deleted completely the target directories, and compiled and instal=
led=20
> sablevm-classpath
>    *before* installing sablevm.
>=20
> and it worked...  Hmmm...  Needs further investigation, but I have no t=
ime
> now to do it.
>=20

Note: If you compile several version and have lib going in
lib/sablevm-inlined, lib/sablevm-direct etc. instead of lib/sablevm.
Well my build CP script will put CP in lib/sablevm and SableVM will
not find it.  Instead of having several CP version, I do a sym link:
cd lib/sablevm-inlined
ln -s ../sablevm

Don't know if it helps.

David

---

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

[Sablevm-developer] Re: sablevm-classpath broken??

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

Weird...

I have redone it, changing two things:
1- in the target location, I changed the name from .../sablevm-inlined to .../sablevminl
2- I deleted completely the target directories, and compiled and installed sablevm-classpath
    *before* installing sablevm.

and it worked...  Hmmm...  Needs further investigation, but I have no time
now to do it.

Etienne

Etienne Gagnon wrote:
> Following the steps in http://devel.sablevm.org/docs/INSTALL.txt with
> current staging does not work for me; *.class are not copied into the
> target directories.
> 
> I did get a clean snapshot, e.g.:
> $ svn st --no-ignore | grep ^I | awk '{print $2}' | xargs rm -rf
> $ svn st --no-ignore
>     => yields nothing
> $ svn info
> Path:
> URL: svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/staging
> Repository UUID: b3b78c83-eebe-0310-8824-bc3aa306739a
> Revision: 1557
> Node Kind: directory
> Schedule: normal
> Last Changed Author: belanger
> Last Changed Rev: 1529
> Last Changed Date: 2004-02-02 00:54:46 -0500 (Mon, 02 Feb 2004)
> Properties Last Updated: 2003-12-01 23:15:01 -0500 (Mon, 01 Dec 2003)
> 
> Etienne
> 


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

[Sablevm-developer] sablevm-classpath broken??

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

Following the steps in http://devel.sablevm.org/docs/INSTALL.txt with
current staging does not work for me; *.class are not copied into the
target directories.

I did get a clean snapshot, e.g.:
$ svn st --no-ignore | grep ^I | awk '{print $2}' | xargs rm -rf
$ svn st --no-ignore
     => yields nothing
$ svn info
Path:
URL: svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/staging
Repository UUID: b3b78c83-eebe-0310-8824-bc3aa306739a
Revision: 1557
Node Kind: directory
Schedule: normal
Last Changed Author: belanger
Last Changed Rev: 1529
Last Changed Date: 2004-02-02 00:54:46 -0500 (Mon, 02 Feb 2004)
Properties Last Updated: 2003-12-01 23:15:01 -0500 (Mon, 01 Dec 2003)

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] Warning: devel release approaching

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

On Tue, 2004-02-10 at 14:46, Chris Pickett wrote:
> Grzegorz B. Prokopski wrote:
> > OTOH I think everybody agrees that we're in a need of release, so I am
> > a bit inclined to loose the requirements *a little bit*, but it'd need
> > to be evaluated on case-by-case basis. That's why I want to know what's
> > the current state compared to old 1.0.9.
> So, do you want me to do it then?  Or will you?
Please go on.

> $ svn ls --username chris svn+ssh://svn.sablevm.org/public
AFAIK --username is for http-dav access only. To specify a username w/ ssh
access go to ./.subversion/config and change the parameters passed to ssh.

> Have you looked at the JGF benchmarks yet?  It's not apparently GPL, 
> LGPL, or public domain code, but the source is available.  I just sent 
> them a mail about licensing.
Good. We'll see. No, I haven't looked yet and I won't be able to do that
for a while (I mean - it's easy to fetch and run it but some more deep
investigation should follow, which I just can't do right now.)

> JGF would be perfect to keep track of things like performance 
> regressions as well.  Please download and run some of the benchmarks so 
> that you see what I mean.
I will give them a try.

> >>I have some code comments that might be useful (e.g. in prepare_code.c, 
> >>types.h ... stuff like that).
> So, I will make a tag for you that can be merged into staging, after we 
> fix JGFSyncBench.
I am looking forward to do it

Cheers,

				Grzegorz B. Prokopski

[Sablevm-developer] Bug#232041: sablevm: Couldn't bind native method Java_java_lang_Runtime_getSableVMVersion

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

tags 232041 pending
thanks

> SableVM's dependencies are broken.  Somehow, apt-get upgrade was able to install unsynchronized
> classlibraries along SableVM's core engine, which leads to a broken package, and breaks other
> software such as SableCC!

This is being worked on. Next upload (hopefully RSN) will fix this
problem.

				GBP

Re: [Sablevm-developer] Threading support in SableVM

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

Chris Pickett wrote:
> It fails in _svmf_enter_object_monitor().  I think Etienne needs to look 
> at it because he wrote the locking stuff ... I would like to participate 
> in debugging it but I don't know where to begin.  Should we try, for 
> example, removing thin locks altogether and see if that fixes it?  Or 
> try making some critical sections bigger?

Chris, it would be nice of you could provide me with the following
in order for me to be able to help you:

Write a small Java application (one class, if possible) that exhibits the
_svmf_enter_object_monitor() problem with the *trunk* of sablevm (i.e. the
"real" 1.0.9 version, not "staging", not a hybrid spmt version).

Thanks,

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] Warning: devel release approaching

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

> OTOH I think everybody agrees that we're in a need of release, so I am
> a bit inclined to loose the requirements *a little bit*, but it'd need
> to be evaluated on case-by-case basis. That's why I want to know what's
> the current state compared to old 1.0.9.

So, do you want me to do it then?  Or will you?

$ svn ls --username chris svn+ssh://svn.sablevm.org/public

does not work for me right now.  It was working last night without the 
username even ... so in the meantime if you have access it is faster for 
you to check 1.0.9.

> The words to remember: _regression tests_ start to be _required_

I think all actual functionality regressions should be eliminated before 
the release.

> Especially if we want to seriously treat our users (and ease our work in
> the long term). Temporarily we can use some proprietary benchmarks and
> the like for this purpose, but eventually - we should have a set of
> little but free tools that stretch the JVM in a few directions. Like
> BTF does it for inlined and architecture-specific problems (ex. in
> arithmetic and signal handling). Ex. Mauve is good, but it targetts
> more Classpath, not the JVM.


Have you looked at the JGF benchmarks yet?  It's not apparently GPL, 
LGPL, or public domain code, but the source is available.  I just sent 
them a mail about licensing.

JGF would be perfect to keep track of things like performance 
regressions as well.  Please download and run some of the benchmarks so 
that you see what I mean.

>>Not all of the JGF bugs seem like threading bugs.
> 
> 
> So we're even more in a need of nailing them down (at least documenting,
> possibly fixing).


I think we should focus on the JGFSyncBench bug and forget about the 
other stuff until that's fixed.  In my opinion, regardless of whether or 
not it's a regression, it's a serious bug -- the Java code that causes 
it is very simple.


>>I have some code comments that might be useful (e.g. in prepare_code.c, 
>>types.h ... stuff like that).
> 
> 
> Maybe at some point (not now) you should try to think about merging
> some of that? We already have some interesting things in sandboxes, but
> if nobody does the work required to make them ready for staging and 
> actually do the integration - these things just get older and don't
> benefit anybody (like hppa port I tried to ressurrect lately or Cygwin
> port in Melanie's sandbox).


So, I will make a tag for you that can be merged into staging, after we 
fix JGFSyncBench.

Chris

[Sablevm-developer] JGF benchmark suite license

[Chris P. <chr...@ma...>]

Hello,

We would like to incorporate the JGF benchmarks as part of a VM 
regression test suite.

Do the JGF benchmarks come with any kind of open source license?

Are they public domain?

Or does standard copyright apply with respect to modification and 
distribution?

All I could find is the copyright notice.

Thanks very much,
Chris Pickett

SableVM
http://www.sablevm.org/

(please CC reply to sab...@li...)

Re: [Sablevm-developer] Warning: devel release approaching

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

> W li=B6cie z wto, 10-02-2004, godz. 00:23, Chris Pickett pisze:=20
>=20
>=20
>>I have some code comments that might be useful (e.g. in prepare_code.c,=
=20
>>types.h ... stuff like that).  I also have a preliminary script (that=20
>>needs refinement) to permute through combinations of options to=20
>>./configure (see permute-options in my sandbox).
>=20
>=20
> So that we didn't double the work, try this:
>=20
> cd
> wget http://gadek.debian.net/testing/testing.tgz
> tar zxvf ./testing.tgz
> cd ./testing
> nohup ./run-all &>./0MAIN.out &
> tail -f ./0MAIN.out
>=20
> Do it somewhere, where you have all sablevm's and classpath's deps
> available, and a fast inet connection. Look into "config" file ;-)
> Then look into the scripts. If you add "benchmarks" to the list of
> TESTS to run and to the list of BINARIES - it'll fetch and run
> SPEC98 benchmarks (that's why I don't advertise this).
>=20
> Warning: once you start it - to stop it you need to kill all these
> processes ;-) Sorry, I was more worried making it actually go.


Really, Greg ... we should sit down with Bruno and discuss his Ashes 2=20
benchmarking framework.  I think we need ONE benchmark system for the=20
whole of Sable, so that nobody wastes time with these little scripts=20
anymore.  It will require learning Python though.

Compiling SableVM is a separate matter though, and as for the=20
compilation stuff in sources-compile-install, look at

http://www.sable.mcgill.ca/~cpicke/files/permute-options

and you'll see how it can be useful almost immediately to generate all=20
possible combinations of options (okay, I just realized it should=20
probably be called "combine-options" ...)

Cheers,
Chris

Re: [Sablevm-developer] Warning: devel release approaching

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

W li=B6cie z wto, 10-02-2004, godz. 00:23, Chris Pickett pisze:=20
> Grzegorz B. Prokopski wrote:
> > - we can make another devel release in a few days if we have importan=
t
> > bugs fixed, I see no reason to impose any requirements on when devel
> > releases can happen
>=20
> In my opinion bugfree should be bugfree to the best of our knowledge.=20
> That's why staging exists.  There's a difference between bugs and=20
> missing features.  I think regressions, if they truly exist, should be=20
> fixed before release (people generally don't like previously working=20
> things to be broken in an upgrade).  Plus I personally could really=20
> benefit from having the threading bugs fixed if they do exist (at this=20
> point I am no longer submitting a paper in the next couple of days, so =
I=20
> can help work on this).

Yes, that's exactly what I mean: _regressions_ - these should be removed
before the release. Ex. I'll be fighting w/ one such today. That's also
why I want to *know* (not suspect) whether things worked w/ released
1.0.9 or not. This doesn't change the fact that these problems are to
be fixed.

But it does change level of the devel-release-readyness of our codebase.
Definitely there should be no regressions in bugfree.

OTOH I think everybody agrees that we're in a need of release, so I am
a bit inclined to loose the requirements *a little bit*, but it'd need
to be evaluated on case-by-case basis. That's why I want to know what's
the current state compared to old 1.0.9.

The words to remember: _regression tests_ start to be _required_

Especially if we want to seriously treat our users (and ease our work in
the long term). Temporarily we can use some proprietary benchmarks and
the like for this purpose, but eventually - we should have a set of
little but free tools that stretch the JVM in a few directions. Like
BTF does it for inlined and architecture-specific problems (ex. in
arithmetic and signal handling). Ex. Mauve is good, but it targetts
more Classpath, not the JVM.

> I also noticed that sometimes mtrt does not produce 100% identical=20
> output (an extra blank line appears at the top).
Yes, mtrt causes many problems, _also_ on single-cpu processors on
_some_ achitectures. They are sometimes more serious than an extra
blank line. It's the state of affairs w/ current staging. Can't say
about 1.0.9 yet. Might be hard to compare on some arches.

> > Question:
> > - Do you know about any other regressions or bugs that we have
> > currently in staging? Please tell us.
>=20
> Not all of the JGF bugs seem like threading bugs.

So we're even more in a need of nailing them down (at least documenting,
possibly fixing).

> I have some code comments that might be useful (e.g. in prepare_code.c,=
=20
> types.h ... stuff like that).

Maybe at some point (not now) you should try to think about merging
some of that? We already have some interesting things in sandboxes, but
if nobody does the work required to make them ready for staging and=20
actually do the integration - these things just get older and don't
benefit anybody (like hppa port I tried to ressurrect lately or Cygwin
port in Melanie's sandbox).

> http://www.sable.mcgill.ca/~cpicke/public_html/files/HACKING.pdf
> if you don't want to check it out of my sandbox.  It's kind of ugly, I=20
> know.  Nobody has actually commented on this work yet -- is there=20
> something totally wrong with the content?
Put on my TODO.

> In my opinion, it might be worth consolidating all of the files in the=20
> sablevm/doc directory into a .texinfo file prior to release.

I like the direction. But let's squash some bugs first, okay? ;-)
(especially if they're regressions)

Cheers,

				Grzegorz B. Prokopski

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

[Sablevm-developer] Extending SableVM with static stack caching

[Heinrich M. <ma...@he...>]

Hi!

As my master's thesis (I'm a computer science student) I want to
evaluate static stack caching. That's an interpreter technique where
you keep the top n stack items in registers to minimize the amount of
necessary memory move operations.

So what I'm planning to do is to take an existing JVM, run some
benchmarks, implement static stack caching (e.g. using vmgen), run the
benchmarks again and evaluate the results.

Therefore, I need a JVM that's (a) stable enough to run the benchmarks
and (b) has clean code so that it is easy to extend. As far as I can
tell from what I've read online, SableVM would be a good choice.

Now I thought I'd ask you a few questions before proceeding:

* What version should I use?

* Did someone already try some benchmarks on SableVM?

* Any other comments or suggestions?


Some other comments:

* "Stable" (as mentioned on <http://www.sablevm.org/getit.html>)
  doesn't seem to be available -- at least I couldn't find a link to
  it anywhere.

* The Wiki cannot be edited with IE or Opera. The reason is the
  <plaintext> tag that's used to display the LGPL. <plaintext> cannot
  be turned off (see RFC 1866: there is no </plaintext>) and is highly
  deprecated.

* Although <http://devel.sablevm.org/docs/INSTALL.txt> claims that
  only libart-dev is required for SABLEVM-CLASSPATH, you (also?) need
  libart-2.0-dev to configure successfully.

* I didn't really test it in-depth but SableVM seems to run well on my
  testing system (user-mode-linux on i386 with Debian sarge/testing).

Sincerely,
    Heinrich

[Sablevm-developer] Bug#232041: sablevm: Couldn't bind native method Java_java_lang_Runtime_getSableVMVersion

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

Package: sablevm
Version: 1.0.9+svn20040120-2
Severity: grave
Justification: renders package unusable

SableVM's dependencies are broken.  Somehow, apt-get upgrade was able to install unsynchronized
classlibraries along SableVM's core engine, which leads to a broken package, and breaks other
software such as SableCC!

$ sablecc -license
*** Couldn't bind native method Java_java_lang_Runtime_getSableVMVersion ***
*** or Java_java_lang_Runtime_getSableVMVersion__ ***
java/lang/UnsatisfiedLinkError
$ 

Thanks for fixing the dependencies.

Etienne

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.24
Locale: LANG=C, LC_CTYPE=C

Versions of packages sablevm depends on:
ii  java-common          0.22                Base of all Java packages
ii  libc6                2.3.2.ds1-11        GNU C Library: Shared libraries an
ii  libffi2              1:3.3.3-0pre3       Foreign Function Interface library
ii  libltdl3             1.5.2-1             A system independent dlopen wrappe
ii  libpopt0             1.7-4               lib for parsing cmdline parameters
ii  libsablevm1          1.0.9+svn20040120-2 Free implementation of JVM second 
ii  unzip                5.50-3              De-archiver for .zip files

-- no debconf information

Re: [Sablevm-developer] Threading support in SableVM

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

> Chris, have you looked at these regressions again? Are they present
> in current staging version too? 

Yes (I just checked).  But I am not sure if it's a regression.  I was 
seeing weird multithreading behaviour with mtrt and my spmt stuff with 
my changes against 1.0.8 -- and while I do not know for sure, my 
intuition at the time (after looking at many instruction traces) was 
that the spmt was slowing down threads long enough for concurrency 
issues with ordinary threads to appear.

Do you have some traces about what
> exactly is happenning? Could you maybe try to debug sablevm behavior?

I posted a while ago asking for more help about this (see message with 
gdb log in response to David)

It fails in _svmf_enter_object_monitor().  I think Etienne needs to look 
at it because he wrote the locking stuff ... I would like to participate 
in debugging it but I don't know where to begin.  Should we try, for 
example, removing thin locks altogether and see if that fixes it?  Or 
try making some critical sections bigger?

> I think that from active developers you might be the person most
> interested in multithreading (and simultanous execution in general),
> so this naturally makes you our 'Multithreading Expert'.

Well, I would say Etienne and Clark are the multithreading experts. 
David likely knows more than me too ... I haven't actually started 
touching pthreads yet in my code.

> This way or another we need to track this issue and fix this. Not being
> able to run benchmarks is *bad* thing in research (and this has impact
> on practical usefulness too!). Looking at it in the long term - do you
> think it would be feasible to create our own test cases/min-apps that
> would stretch and excersise SableVM's threads? 

The JGF benchmarks include many micro benchmarks.  They really are a lot 
more useful than SPEC and JOlden, in my opinion, for finding 
small-yet-critical bugs and optimizing performance of specific things.

> But of course the first thing now would be to track this issue and try
> to fix it. I guess David could help w/ Classpath/SableVM glue code as he
> has lots of experience there and this is most probably the source of
> our problems.


Can somebody check this quickly on 1.0.9 or an earlier version?

Maybe all of the Montreal developers should get together to discuss 
1.1.0, and plans for the future?  We haven't had a multiple person 
meeting (at least one that involved me!) in a long time ...

Cheers,
Chris

Re: [Sablevm-developer] Warning: devel release approaching

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:
> Hi all!
> 
> Now disclaimers:
> - we need to document our numbering schema in Wiki (I'll do this)

I think I have most of this already written (see below).

> - we can make another devel release in a few days if we have important
> bugs fixed, I see no reason to impose any requirements on when devel
> releases can happen

In my opinion bugfree should be bugfree to the best of our knowledge. 
That's why staging exists.  There's a difference between bugs and 
missing features.  I think regressions, if they truly exist, should be 
fixed before release (people generally don't like previously working 
things to be broken in an upgrade).  Plus I personally could really 
benefit from having the threading bugs fixed if they do exist (at this 
point I am no longer submitting a paper in the next couple of days, so I 
can help work on this).

> - apparently we have a regression in threading support as compared
> to 1.0.9 release and I don't think we can release 1.2.0 w/ this unfixed,
> but holding devel release will hurt more, than this problem alone.

Is this the JGFSyncBench bug I was talking about?

I also noticed that sometimes mtrt does not produce 100% identical 
output (an extra blank line appears at the top).

> Question:
> - Do you know about any other regressions or bugs that we have
> currently in staging? Please tell us.

Not all of the JGF bugs seem like threading bugs.

> PS: I want the above to happen really soon now. I am just having
> troubles making new classpath compile like I'd like it to be
> (but it's debian specific thing, no worries) so it takes longer
> than I'd like it to be. But I am really working on it.

I have some code comments that might be useful (e.g. in prepare_code.c, 
types.h ... stuff like that).  I also have a preliminary script (that 
needs refinement) to permute through combinations of options to 
./configure (see permute-options in my sandbox).

I also have some stuff on:

1) Policies for contributing to SableVM
2) How to access Subversion
3) Branch management
4) Coding style

I tried making a .tex file with it, although I don't think that's a good 
way to go.  .texinfo would be much more useful (just like classpath). 
In any case, you can see it in .pdf format at:

http://www.sable.mcgill.ca/~cpicke/public_html/files/HACKING.pdf

if you don't want to check it out of my sandbox.  It's kind of ugly, I 
know.  Nobody has actually commented on this work yet -- is there 
something totally wrong with the content?

In my opinion, it might be worth consolidating all of the files in the 
sablevm/doc directory into a .texinfo file prior to release.

Cheers,
Chris

[Sablevm-developer] Threading support in SableVM

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

Hi Chris, hi everybody,

I've just re-read the reports about JGF benchmarsk and I am really
worried by how it looks. Especially that we didn't know previously that
there were problems. I have problems on SMP machines but that's not
a _regression_. But apparently we have some _regressions_, especially
in threading.

Chris, have you looked at these regressions again? Are they present
in current staging version too? Do you have some traces about what
exactly is happenning? Could you maybe try to debug sablevm behavior?
I think that from active developers you might be the person most
interested in multithreading (and simultanous execution in general),
so this naturally makes you our 'Multithreading Expert'.

This way or another we need to track this issue and fix this. Not being
able to run benchmarks is *bad* thing in research (and this has impact
on practical usefulness too!). Looking at it in the long term - do you
think it would be feasible to create our own test cases/min-apps that
would stretch and excersise SableVM's threads? I *will* be running
regular tests of SableVM soon and I could put them in test set (they
should ideally produce some output that I could compare w/ the expected
one and register success/failure of such test).

But of course the first thing now would be to track this issue and try
to fix it. I guess David could help w/ Classpath/SableVM glue code as he
has lots of experience there and this is most probably the source of
our problems.

I don't imagine we can release stable SableVM 1.2.0 w/ (slightly) broken
threads. We might not support some features, but the existing ones
cannot be broken.

Cheers,

				Grzegorz B. Prokopski

[Sablevm-developer] Warning: devel release approaching

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

Hi all!

Today David and I were granted write access to "bugfree"s. I have some
ideas how/when I see the devel release should happen, but I'd like to
hear comments, if you have better/different ideas/beliefs about it.

The plan - how I see it:
- I put current staging (preferably tarball created w/ 'make dist' into
Debian and let people (and autobuilders) test it for a short while
- make necessary bug fixes, but if there're not major showstoppers
- move current staging to bugfree and make a release (by a request
to Etienne to make a tags for it)
(and I finally package 1.1.0 for Debian ;-)

Now disclaimers:
- we need to document our numbering schema in Wiki (I'll do this)
- we can make another devel release in a few days if we have important
bugs fixed, I see no reason to impose any requirements on when devel
releases can happen
- apparently we have a regression in threading support as compared
to 1.0.9 release and I don't think we can release 1.2.0 w/ this unfixed,
but holding devel release will hurt more, than this problem alone.
- we should have a step-by-step "making a release" process described,
like ex. subversion (or ArgoUML?) guys have (I'll do this too)
- under the assumption that all bugs in SableVM are also present
in its Debian version - we encourage people to use Debian BTS,
(or -devel ML - after all it's _devel_ release).

Question:
- Do you know about any other regressions or bugs that we have
currently in staging? Please tell us.

If we're to wait for ideal conditions to make a release - they will
never happen. We have what we have and IMO it is more than good enough
for people to test it. In most of areas it is far superior to old 1.0.9.
And w/o testing we wont make it really bugfree.

Cheers,

				Grzegorz B. Prokopski

PS: I want the above to happen really soon now. I am just having
troubles making new classpath compile like I'd like it to be
(but it's debian specific thing, no worries) so it takes longer
than I'd like it to be. But I am really working on it.