sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] Report: SableVM on various architectures

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

Hi all!

Another update: alpha works w/ inlined now. We have 6 arches w/ inlined!

Remaining to get (inlined) working:
s390 - haven't managed to get around it yet, direct works,
arm - broken w/ any engine, but port machine is unreachable currently
hppa - direct works, tausq offered help in trying inlined on his machine
  (Debian port machine behaves strangely, and we HAD it working on
   tausq's hppa)
mips/mipsel - At first I didn't know that there's libffi for them, and
   currently the port machines are unaccessible

Next victims / goals: arm (if machine is back), s390.


About alpha:

The arch is weird, I had to detect some magic value 128 of info->si_code
(in signal handler) that I don't find any #define for in /usr/include/*.
We get this sig code on division by 0. I guess this may be a kernel bug.

PUTSTATIC_*/PUTFIELD_* aren't inlinable at all (I haven't looked at the
assembly, but I think it'd be interesting to take a look), while
GETFIELD_* are inlinable only w/ signals. I think it's the only such
arch so far. Besides these, only LDC_STRING, FREM, DREM are
noninlinable.

svn diff -r 1554:1555 svn+ssh://svn.sablevm.org/sablevm/branches/staging
will tell you the story in details.

Cheers,

					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

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

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

On Sun, Feb 08, 2004 at 02:48:46AM -0500, Grzegorz B. Prokopski wrote:
> Hi guys!
>=20

Hi Greg,

> AFAIK there were some problems w/ Solaris port of SableVM, like:
> - you had to fix libffi,

yes.

> - in classpath you changed file longint to standard int (which
> would suggest that 64-bit value handling was broken?)

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.

> Have the libffi fixes for Solaris been pushed upstream?
> Where's the diff of them?
>=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.


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

Yes.

> Does SableVM on Solaris run BTS tests properly on all engines?
>=20
> Are there any other problems I ommited above?
>=20
> Is there anything missing so that one could simply checkout SableVM and
> GNU Classpath from SVN/staging and compile it (and run/use) on Solaris?
>=20
> I'd be interested in hearing what are the plans regarding this port,
> and how do you feel about its current state.

I will let Christian comment on this part, I don't know which change
was done in SableVM and if they have been pushed to staging.


Note: Next week we will merge my most recent SableVM/SableJIT changes
      into Christian branch.  At that point, we could check diffs
      and push SableVM changes, if any, to staging.


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] Bug#231727: sablevm: should support the -jar argument...

[Arnaud V. <av...@de...>]

Package: sablevm
Version: 1.0.9+svn20040120-2
Severity: normal

Hi Grzegorz,

Here is a mail I did send to kaffe and gij (gcj). I'd like virtual
machine to support the meta-inf/manifest.mf fields and the -jar
argument.

Is it possible?

Thanks for your time,

Cheers,


You can find the post here:
http://www.kaffe.org/pipermail/kaffe/2004-February/045189.html

                                 --><--

To: ka...@ka...
Subject: kaffe -jar should recursively set meta-inf/manifest.mf#Class-Path
X-Draft-From: ("nnml:kaffe" "")
From: Arnaud Vandyck <arn...@ul...>
Date: Sat, 07 Feb 2004 23:30:12 +0100
Message-ID: <874...@oz...>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0


Hi all,

I was trying something (to prepare my talk with Dalibor at the FOSDEM;))
and the way IBM's JDK (1.4.1) does it is perfect for me!.. But kaffe
does not do it the same way.

$ java -jar test1.jar

great
great

$ kaffe -jar test1.jar

great
java.lang.NoClassDefFoundError: test3/Test3
   at test2.Test2.print2 (Test2.java:26)
   at test.Test1.main (Test1.java:23)
   at java.lang.reflect.Method.invoke0 (Method.java)
   at java.lang.reflect.Method.invoke (Method.java:255)
   at kaffe.jar.ExecJarName.main (ExecJarName.java:67)
   at kaffe.jar.ExecJar.main (ExecJar.java:75)

The classes and manifest files and jar files are attached.

What was I trying to do?

You probably know that you can specify a classpath in a manifest
file. If you run java with -jar theapplication.jar, java will search for
Main-Class field to execute the class and also to the Class-Path field
to 'dynamically' set the classpath.

I was wondering if a jar depends of a jar that depends of another, what
happens? With IBM runtime, if the second library has a correct
Class-Path field in its manifest file, then, the dependency is
resolved. But in kaffe, it's not the case.

Would it be possible to change the behavior of kaffe to make it resolve
the classpath with the -jar argument recursively?

I hope the explanation was correct...

Many thanks for your attention and time, cheers,

-- 
Arnaud


Content-Type: text/x-java
Content-Disposition: attachment; filename=Test1.java

package test;

import test2.Test2;

/**
 * Test1.java
 *
 *
 * Created: Sat Feb  7 11:50:54 2004
 *
 * @author <a href="mailto:arnaud@localhost">Arnaud Vandyck</a>
 * @version 1.0
 */

public class Test1{
  public Test1() {
    
  }
  
  public static void main(String[] args) {
    Test2 tt = new Test2();
    System.out.println(tt.print());
    System.out.println(tt.print2());
    
  }
} // Test1


Content-Type: text/x-java
Content-Disposition: attachment; filename=Test2.java

package test2;

import test3.Test3;

/**
 * Test2.java
 *
 *
 * Created: Sat Feb  7 11:51:48 2004
 *
 * @author <a href="mailto:arnaud@localhost">Arnaud Vandyck</a>
 * @version 1.0
 */
public class Test2 {
  public Test2() {
    
  } // Test2 constructor

  public String print()
  {
    return "great";
  }

  public String print2()
  {
    Test3 tt = new Test3();
    return tt.print();
  }
  
} // Test2


Content-Type: text/x-java
Content-Disposition: attachment; filename=Test3.java

package test3;

/**
 * Test3.java
 *
 *
 * Created: Sat Feb  7 11:51:48 2004
 *
 * @author <a href="mailto:arnaud@localhost">Arnaud Vandyck</a>
 * @version 1.0
 */
public class Test3 {
  public Test3() {
    
  } // Test3 constructor

  public String print()
  {
    return "great";
  }

} // Test3


Content-Disposition: attachment; filename=manifest.test1

Manifest-Version: 2.0
Main-Class: test.Test1
Class-Path: test2.jar 


Content-Disposition: attachment; filename=manifest.test2

Manifest-Version: 2.0
Class-Path: test3.jar

[Sablevm-developer] SableVM/Solaris status report request

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

Hi guys!

AFAIK there were some problems w/ Solaris port of SableVM, like:
- you had to fix libffi,
- in classpath you changed file longint to standard int (which
would suggest that 64-bit value handling was broken?)

Have the libffi fixes for Solaris been pushed upstream?
Where's the diff of them?

Have the problem w/ 64-bit values been fixed?

Does SableVM on Solaris run BTS tests properly on all engines?

Are there any other problems I ommited above?

Is there anything missing so that one could simply checkout SableVM and
GNU Classpath from SVN/staging and compile it (and run/use) on Solaris?

I'd be interested in hearing what are the plans regarding this port,
and how do you feel about its current state.

Thanks in advance,

				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

[Sablevm-developer] profiling SableVM?

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

Hi,

Has anybody had any luck with profiling SableVM?  I need to do this to 
cut down on the overhead of my speculative multithreading work, because 
currently benchmarks take too long to execute for an efficient 
write-compile-test-debug cycle.

I tried gprof 2.12.90.0.1, but it doesn't work for multithreaded C 
applications like SableVM (this is apparently a well-known problem with 
gprof).

I tried the pthread_create() wrapper for use with gprof found here:

http://sam.zoy.org/writings/programming/gprof.html

but have had no luck with it (same gprof output as before setting 
LD_PRELOAD=~/gprof-helper.so -- I found the single call to 
pthread_create in SableVM and looked at the gprof-helper.c code but 
could not see any obvious problem ...)

I looked at Prospect:

http://prospect.sourceforge.net/

and OProfile:

http://oprofile.sourceforge.net/news/

but Prospect depends on OProfile and OProfile requires kernel sources 
(which I cannot find on the Sable lab machines -- I tried simply 
downloading the sources but OProfile's configure requires the specific 
sources used to build the kernel).

Finally, I tried installing FunctionCheck 3.0.11 and FunctionDump 3.0.5, 
but was having errors getting FunctionDump to compile because of a 
missing bfd library (again something I couldn't find, although I did 
manage to tell autoconf to look in ~/include for bfd.h, put there by 
gcc-3.3.2).  This tool has been abandoned, with only the SF pages left.

http://sourceforge.net/projects/fnccheck/

So ... any comments would be greatly appreciated.  I'll email the 
gprof-helper.c maintainer, but I wanted to see if someone has already 
got a solution for this.

Cheers,
Chris

Re: [Sablevm-developer] Java_java_lang_VMRuntime_exit and stats

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

Hi David,

My understanding of System.exit()'s API docs is that calling exit() is
the right thing, so:

> 2) Or should I simply isolates stats code in new function and
>    call it at exit points and DestroyJavaVM

This would be the right thing to do.  DestroyJavaVM wasn't the appropriate
place for it, anyway.  It was a simple hack to directly put the code in its body.

Etienne

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

[Sablevm-developer] Java_java_lang_VMRuntime_exit and stats

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

Hi,

I noticed that Java_java_lang_VMRuntime_exit is implemented as a
simple exit(status).

If the VM exits by returning from main method, DestroyJavaVM will be call=
.

Not sure if DestroyJavaVM should be called from all exit points.

However VM stats (-DSTATISTICS) are printed in DestroyJavaVM.  So they
do not get always printed on VM exit...

1) Does DestroyJavaVM need to be called at every exit point?
2) Or should I simply isolates stats code in new function and
   call it at exit points and DestroyJavaVM


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] Bug#231359: SableVM improper version name

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

W li=B6cie z czw, 05-02-2004, godz. 22:48, Adam Majer pisze:=20
> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Versi=
on

I've read that three times. Especially the section about the
debian_revision. And I don't find anything that says that if the
package has upstream ./debian dir then I cannot use -1 -2 etc.

So I guess that ex. 1.1.0-1 is fully allowed. The 1.1.0 would be the
upstream version and -1 would be the debian version which is true.
Else I'd need to "invent" upstream versions, like 1.1.0.1 - which is
*very bad* and confusing idea.

Actually it was creatively stimulating lecture - see this:

$ dpkg --compare-versions 1.0.9-20040205-1 '>' 1.0.9+svn20040102-2 &&
echo true || echo false

says: "true", so I can upload 1.0.9-20040205-1 where upstream version is
1.0.9-20040205 and debian revision is 1 !

Cool! and thanks :-)

					Grzegorz B. Prokopski

PS: It's good to be RTFMed to some good docs.
--=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] Bug#230235: Fails with "Couldn't bind native method Java_gnu_java_awt_peer_gtk_GdkPixbufDecoder_initStaticState"

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

W li=B6cie z czw, 29-01-2004, godz. 06:52, Falk Hueffner pisze:=20
> I'm trying to run a jar from
> http://62.138.43.170/de/Community/InstData/Java/install.jar:
>=20
> falk@juist:/tmp% java -jar install.jar=20
> *** Couldn't bind native method Java_gnu_java_awt_peer_gtk_GdkPixbufDec=
oder_initStaticState ***
> *** or Java_gnu_java_awt_peer_gtk_GdkPixbufDecoder_initStaticState__ **=
*
> sablevm: INTERNAL ERROR (source file "error.c", line 182): unexpected f=
loating point signal
> zsh: abort (core dumped)  java -jar install.jar

Actually there are at least two problems. First is that on alpha
handling of some numerical operations is apparently much different
than on ex. Intel. Many architectures have been fixed already.

It's not terribly hard to fix. All I need to know is on which line
of code that handles bytecode interpreteation (big switch in
instructions_* files) it fails, or at least which bytecode.

Thus if you want to help - you could use gdb/ddd to check where it fails
and tell me. To help with this task you can use our small but extremly
useful testing classes available at:
http://gadek.debian.net/testing/sablevm-test-suite.tgz
(warning: it unpacks to the current dir)

Try HelloWorld (should work pretty much always)
and BytecodeVerificationTest (should catch all problems).

Feel free to mail me if you have problems or catch me on #sablevm
or #debian-devel at irc.{debian|sablevm}.org, nick: gadek.

Cheers,

				Grzegorz B. Prokopski

PS: The other problem you'd hit w/ current version is #231365.
That's what I hit when trying to run the jar you pointed on
intel arch. But this one should be fixed soon.

--=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] Bug#230158: marked as done (libsablevm-native1 depends on X)

[<ow...@bu...>]

Your message dated Thu, 5 Feb 2004 20:56:51 -0800
with message-id <E0D...@da...>
and subject line Libsablevm native depends on X
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--------------------------------------
Received: (at submit) by bugs.debian.org; 28 Jan 2004 22:57:03 +0000
>From aj...@da... Wed Jan 28 14:57:03 2004
Return-path: <aj...@da...>
Received: from daisho.cybercom.net (daisho.us) [64.46.156.71] 
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1AlycI-0001Rc-00; Wed, 28 Jan 2004 14:57:03 -0800
Received: from aj by daisho.us with local (Exim 4.30)
	id 1Alygc-000396-GC; Wed, 28 Jan 2004 18:01:30 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: aj <aj...@da...>
To: Debian Bug Tracking System <su...@bu...>
Subject: libsablevm-native1 depends on X
X-Mailer: reportbug 2.39
Date: Wed, 28 Jan 2004 18:01:30 -0500
Message-Id: <E1A...@da...>
Delivered-To: su...@bu...
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_01_27 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no 
	version=2.60-bugs.debian.org_2004_01_27
X-Spam-Level: 

Package: libsablevm-native1
Version: 1.0.9-1
Severity: minor

I want to do free java development without installing libart and libgtk
or anything x-windows related.

Could we move these dependancies to reccomends?

I suppose a seperate package for Swing stuff would be asking too much.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux daisho 2.4.21 #2 Mon Aug 25 22:46:36 EDT 2003 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages libsablevm-native1 depends on:
ii  java-common                 0.22         Base of all Java packages
ii  libc6                       2.3.2.ds1-10 GNU C Library: Shared libraries an

-- no debconf information


---------------------------------------
Received: (at 230158-done) by bugs.debian.org; 6 Feb 2004 04:56:50 +0000
>From aj...@da... Thu Feb 05 20:56:50 2004
Return-path: <aj...@da...>
Received: from daisho.cybercom.net (daisho.us) [64.46.156.71] 
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1Aoy2s-0002lZ-00; Thu, 05 Feb 2004 20:56:50 -0800
Received: from adsl-63-202-186-213.dsl.snfc21.pacbell.net ([63.202.186.213] helo=daisho.us)
	by daisho.us with asmtp (TLS-1.0:RSA_3DES_EDE_CBC_SHA:24)
	(Exim 4.30)
	id 1Aoy7b-0005c3-G4
	for 230...@bu...; Fri, 06 Feb 2004 00:01:43 -0500
Date: Thu, 5 Feb 2004 20:56:51 -0800
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Libsablevm native depends on X
From: aj <aj...@da...>
To: 230...@bu...
Content-Transfer-Encoding: 7bit
Message-Id: <E0D...@da...>
X-Mailer: Apple Mail (2.553)
Delivered-To: 230...@bu...
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_02_01 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no 
	version=2.60-bugs.debian.org_2004_02_01
X-Spam-Level: 

Maintainer says depending on X is the best way to package it.

I am a fan of X and noX packages, but can see how that would be a PITA 
for the maintainer.

close it.

-aj

[Sablevm-developer] Re: No anonymous access to SVN

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

Grzegorz B. Prokopski wrote:
> Anonymous access is nice - I don't have to put my ssh keys on
> remote machines. It'd be even nicer to have it back. ;-)


Restored.  svnserve's command-line options have changed.  I should have
RTFM when apt-get upgrading, I guess... :-)

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] No anonymous access to SVN

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

Hi!

I guess there's some problem w/ anonymous access to SVN. See this:
$ svn ls svn://svn.sablevm.org/       
svn: Malformed network data
svn: Malformed network data

$ svn ls svn+ssh://svn.sablevm.org/public/
archives/
developers/
sablecc/
sablecc-ant-task/
sablecc-grammars/
sablejit/
sablevm/
sablevm-classpath/
sablevm-test-suite/
websites/

Anonymous access is nice - I don't have to put my ssh keys on
remote machines. It'd be even nicer to have it back. ;-)

Cheers,

				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

[Sablevm-developer] Bug#231365: undefined symbol: g_thread_init

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

Package: sablevm
Version: 1.0.9+svn20040120-2
Tags: upstream, pending
Submitter: James Damour <jd...@ny...>

(submitting to BTS to keep track of this issue)

W li=B6cie z czw, 05-02-2004, godz. 14:33, James Damour pisze:=20
> On Tue, 2004-02-03 at 00:22, Grzegorz B. Prokopski wrote:
> > So you'd better try the above debs ;-)
>=20
> Thanks!  Using those, I got my simple "Hello World" program to run (as
> well as my most simplest of test programs).
Good!

> However, I'm having running
> my test programs that (a) use serialization, and (b) use a UI.  If you
> have the time, can you help me?
>=20
> The UI is probably the most simplest to debug.  When I run with the
> verbose flag, I get the following output (*much* truncated for clarity'=
s
> sake):
> [verbose class: loading "gnu/java/awt/peer/gtk/GtkMainThread"]
> [verbose class: loading "gnu/java/awt/peer/gtk/GtkGenericPeer"]
> sablevm: relocation error: /usr/lib/sablevm/classpath/libgtkpeer.so:
> undefined symbol: g_thread_init
>=20
> Either I need to run with a different threading model (please let me
> know how to do this), or the GTK peer library wasn't compiled with the
> correct threading model. =20

This bug was introduced in GNU Classpath CVS after last release of GNU CP
and was also fixed quite recently. Because we pull from GNU CP CVS,
you were biten by this bug.

And for the same reason next upload (today or tomorrow) should fix this
particular problem. Working on it. I hope you'll be able to get further.

HTH

				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] Bug#231366: Serialization in SableVM

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

Package: sablevm:
Version: 1.0.9+svn20040120-2
Tags: pending, upstream
Submitter: James Damour <jd...@ny...>

W li=B6cie z czw, 05-02-2004, godz. 14:33, James Damour pisze:=20
> The serialization is a bit harder.  The last few lines of the verbose
> output (I *think* that these are the important ones) are:
> [verbose class: loading "java/io/ObjectOutputStream"]
> [verbose class: loading "java/io/ObjectOutput"]
> [verbose class: loading "java/io/ObjectStreamConstants"]
> [verbose class: loading "java/io/CharArrayWriter"]
> [verbose class: loading "java/io/StringWriter"]
> [verbose class: loading "java/io/ByteArrayInputStream"]
> [verbose class: loading "java/io/StreamTokenizer"]
> [verbose class: loading "java/io/PushbackReader"]
> [verbose class: loading "java/io/FilterReader"]
> [verbose class: loading "java/lang/Double"]
> [verbose class: loading "megamek/common/Terrain"]
> [verbose class: loading "megamek/common/Coords"]
> [verbose class: loading "megamek/common/Building"]
> [verbose class: loading "java/util/Vector$1"]
> [verbose class: loading "megamek/common/BoardEvent"]
> [verbose class: loading "java/util/EventObject"]
> [verbose class: loading "megamek/common/InfernoTracker"]
> [verbose class: loading "megamek/common/RoundUpdated"]
> [verbose class: loading "megamek/common/InfernoTracker$Inferno"]
> [verbose class: loading "gnu/java/io/ObjectIdentityWrapper"]
> [verbose class: loading "java/io/ObjectStreamClass"]
> [verbose class: creating "[Ljava/lang/reflect/Method;"]
> [verbose class: loading "java/io/ObjectStreamField"]
> [verbose class: creating "[Ljava/io/ObjectStreamField;"]
> [verbose class: loading "gnu/java/io/NullOutputStream"]
> [verbose class: loading "java/io/InterfaceComparator"]
> [verbose class: loading "java/io/MemberComparator"]
> [verbose class: creating "[Ljava/io/ObjectOutputStream;"]
> [verbose class: loading "java/lang/reflect/Proxy"]
> [verbose class: creating "[Ljava/lang/reflect/Proxy;"]
> [verbose class: loading "java/io/Externalizable"]
> [verbose class: creating "[Ljava/io/Externalizable;"]
> [verbose class: creating "[Ljava/io/Serializable;"]
> [verbose class: creating "[Ljava/lang/reflect/Field;"]
> [verbose class: loading "gnu/java/lang/reflect/TypeSignature"]
> [verbose class: loading "megamek/common/He"]
> [verbose class: loading "java/io/ObjectStreamException"]
> [verbose class: loading "java/io/IOException"]
> [verbose class: creating "[Ljava/lang/StackTraceElement;"]
> [verbose class: loading "java/lang/Throwable$StaticData"]
> java.lang.ClassNotFoundException: megamek.common.He
>    at gnu.java.lang.SystemClassLoader.findClass
> (SystemClassLoader.java:79)
>    at java.lang.ClassLoader.loadClass (ClassLoader.java:327)
>    at java.lang.ClassLoader.createArray (ClassLoader.java:369)
>    at java.lang.VirtualMachine.createArray (VirtualMachine.java:102)
>    at java.lang.reflect.Field.nativeGetType (Field.java)
>    at java.lang.reflect.Field.getType (Field.java:175)
>    at java.io.ObjectStreamClass.setFields (ObjectStreamClass.java:557)
>    at java.io.ObjectStreamClass.ObjectStreamClass
> (ObjectStreamClass.java:465)
>    at java.io.ObjectStreamClass.lookupForClassObject
> (ObjectStreamClass.java:99)   at java.io.ObjectOutputStream.writeObject
> (ObjectOutputStream.java:282)
>    at megamek.test.xml.TestBoardEncoder.main (TestBoardEncoder.java:80)
>    at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
>    at java.lang.VirtualMachine.main (VirtualMachine.java:88)
> [verbose gc: total gc time =3D 0 sec 0 usec]
>=20
> As you can see, the error comes when I attempt to write an object to th=
e
> ObjectOutputStream.  Several of the members of the object being
> serialized are found without trouble (the Terrain, Coords, Building, an=
d
> other members of megamek.common package), but it dies trying to find th=
e
> class for "megamek.common.He"; please note, there *IS* no
> "megamek.common.He".  There is a megamek.common.Hex, and the object
> being serialized contains an array of Hex, so I *think* that is what
> it's going for.  Is there some way that I can tell for certain?  Should
> I attempt to fire up gdb and step through the sablevm code?  Will that
> even work?  I figure that **this** is the bug that would be most
> interesting to you as a JVM developer.
>=20
> If you don't feel like debugging by remote, I'll be making a new
> snapshot release of my project this weekend, so you could consider
> downloading the project from http://sourceforge.net/projects/megamek an=
d
> running the tests for yourself.  Unlike the recommendations of the
> debian-java list, I include *both* source *and* compiled binaries
> (including third party libraries and a Class-Path entry in the
> MANIFEST), so you can use the code that I compiled.

I believe that serialization is at the moment broken w/ current SableVM
as the object serial no.s have been commented out. It was because of
Sun's javac handling of constans. But decision was made to move these
IDs back anyway. I would like to see it done soon. I'll do this change
in SableVM debian packages.

Not sure if there are any other problems w/ serialization which you
might expect. If it doesn't help - we should ask on GNU Classpath ML.

Or, in fact, you can ask for status of serialization support right now.

HTH

					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] Bug#231359: SableVM improper version name

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

Package: sablevm
Version: 1.0.9+svn20040120-2

Hi,

A couple of answers.

As for the upstream version - after 1.0.9 and 1.0.9test (which was
already bad version name, apparently) I just looked for something higher
than 1.0.9test and lower than 1.0.10. The "+" just worked.

So now probably I'll probably change the version to sth. like:
1.0.9.20040120-1. And of course there should be no .orig.tar.gz
(after 1.0.9 - there's none already).

> "upstream" doesn't have to exactly as upstream has it - it
> can contain more than one package, even some changes (removals)
> are allowed if upstream contains non-free stuff that
> cannot be distributed. Even with all of these changes
> you can still have a .orig.tar.gz and .diff.gz.
The idea is to have upstream as near debian version, as possible.
Ideally, and this is the case right now, I simply get the SableVM
source, put ./debian dir content into it and it should work.
If it doesn't - then sth. in SableVM is broken ;-)

I am submitting this as a bug, to keep record of these things.
Hopefuly I'll be uploading new SableVM soon fixing it.

Thanks for pointing this problem out.

Cheers

				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] problem with svn access

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

It's migrated.

Have fun!

Etienne Gagnon wrote:
> Thanks to debian's apt-get upgrade, I got subversion 0.37.x on the
> server, which has a different repository format. :-)
>=20
> OK, I'm upgrading the repository to new format.  Will send a message
> when done.
>=20
> Etienne
>=20
> David B=E9langer wrote:
>=20
>> Etienne,
>>
>> Christian and I are having this problem with svn:
>>
>> ibou:~/work/svn_sablejit/belanger/sandbox/sablejit-classpath/sablevm>
>> svn ls
>> ../subversion/libsvn_repos/repos.c:969: (apr_err=3D165005)
>> svn: Unsupported repository version
>> svn: Expected version '3' of repository; found version '2'
>> ibou:~/work/svn_sablejit/belanger/sandbox/sablejit-classpath/sablevm>
>> Same problem on Solaris with Etienne version.
>>
>> Meanwhile, will upgrade to 0.37 to see.
>=20
>=20


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

Re: [Sablevm-developer] problem with svn access

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

Thanks to debian's apt-get upgrade, I got subversion 0.37.x on the
server, which has a different repository format. :-)

OK, I'm upgrading the repository to new format.  Will send a message
when done.

Etienne

David B=E9langer wrote:
> Etienne,
>=20
> Christian and I are having this problem with svn:
>=20
> ibou:~/work/svn_sablejit/belanger/sandbox/sablejit-classpath/sablevm>
> svn ls
> ../subversion/libsvn_repos/repos.c:969: (apr_err=3D165005)
> svn: Unsupported repository version
> svn: Expected version '3' of repository; found version '2'
> ibou:~/work/svn_sablejit/belanger/sandbox/sablejit-classpath/sablevm>=20
>=20
> Same problem on Solaris with Etienne version.
>=20
> Meanwhile, will upgrade to 0.37 to see.

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

[Sablevm-developer] problem with svn access

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

Etienne,

Christian and I are having this problem with svn:

ibou:~/work/svn_sablejit/belanger/sandbox/sablejit-classpath/sablevm>
svn ls
../subversion/libsvn_repos/repos.c:969: (apr_err=3D165005)
svn: Unsupported repository version
svn: Expected version '3' of repository; found version '2'
ibou:~/work/svn_sablejit/belanger/sandbox/sablejit-classpath/sablevm>=20

Same problem on Solaris with Etienne version.

Meanwhile, will upgrade to 0.37 to see.

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] Bug#229820: /usr/bin/java-sablevm: bashisms: patch

[W. <jwa...@be...>]

Le sam 31/01/2004 =C3=A0 21:25, Grzegorz B. Prokopski a =C3=A9crit :
> W li=C5=9Bcie z sob, 31-01-2004, godz. 13:56, J=C3=A9r=C3=B4me Warnier pi=
sze:=20
> > The first line change is correct.
> >=20
> > For the second one, I'm not absolutely sure, please double-check.
> >=20
> > Hope it helps.
>=20
> Of course it does!
>=20
> I'd love to apply these changes, it's just that sablevm package is
> currently stuck in NEW queue since more than a week. Hopefully it's
> just because ftpmasters were moving to some other machine.
Seems it has landed into Sid, and this bug is the only one left keeping
it from going into Sarge...

> Thank you for your help,
>=20
> 				Grzegorz B. Prokopski
>=20
> PS: In the meantime the version stuck in new is available at
> http://gadek.debian.net/sablevm-unofficial/
> this file contains all the latest binary debs
> http://gadek.debian.net/sablevm-unofficial/sablevm-alldebs.tgz
> (but w/o fix for this particular bug yet)
--=20
J=C3=A9r=C3=B4me Warnier <jwa...@be...>
BeezNest s.=C3=A0 r.l.

Re: [Sablevm-developer] Report: SableVM on various architectures

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

On Tue, Feb 03, 2004 at 01:22:08AM -0500, Grzegorz B. Prokopski wrote:
> I've just finished updating my testing scripts to run some benchmarks
> and I am going to throw them at these architectures (w/ exception of
> ppc as I don't have any and I am not sure what about m68k, as the
> compilation of sablevm takes 2-3 hours, then running benchmarks may
> take a week... or two ;-)

Hi Greg,

You can be pretty confident that it works fine on Linux/powerpc, I am
using it as my main development platforms.  Runs all the SPECjvm98
benchmarks no problem.


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] summary of JGF benchmark problems

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

>> Do you mean that you encounter problems with these benchmarks
>> using current staging version of SableVM? or your modified version?
>>
> 
> With my (shouldn't be broken) merge of SableVM into the switch 
> interpreter.  You're right ... I should test this against a vanilla 
> staging ... but I'm pretty confident that I haven't actually made any 
> changes against the plain switch interpreter (all the spmt stuff is 
> #ifdef'd away).

Or you can just forget about it and wait for me to test it again on the 
current staging, to really confirm that it's 100% not my fault.  None of 
this is urgent for me.  Sorry if I gave the impression that it was. 
Rather, just a bug report, which I'd like to help fix.

Chris

Re: [Sablevm-developer] Report: SableVM on various architectures

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

Update:

ARM also breaks running any engine, it looks just like on Alpha.
HPPA is having problems w/ inlined [*], direct works fully.
M68K works fully, inlined inlcluding.

So the list of arches w/ fully working inlined is now:

	i386, ia64, ppc, sparc, m68k

Fully working direct:

	hppa, s390


I've just finished updating my testing scripts to run some benchmarks
and I am going to throw them at these architectures (w/ exception of
ppc as I don't have any and I am not sure what about m68k, as the
compilation of sablevm takes 2-3 hours, then running benchmarks may
take a week... or two ;-)

[*] I have to search for this mail tomorrow but I guess that while
working w/ tausq we got inlined to at least run HelloWorld. And now
it severly segfaults :-( That'd be the first thing to check.

Alpha, ARM and s390 all seem to have quite similar symptoms. But I have
to go down the machine code to find out what it is. Looks like I've just
made plans for this weekend...

I also found out that libffi IS available on MIPS (not 100% sure about
MIPSEL) though it doesn't have all the features. But it should be good
enough for what SableVM needs. Debian-mips ML contacted, no reply yet.

Cheers,

					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

[Sablevm-developer] Accepted sablevm 1.0.9+svn20040120-2 (i386 source all)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 22 Jan 2004 23:06:38 -0500
Source: sablevm
Binary: libsablevm1 sablevm jikes-sablevm libsablevm1-dev
Architecture: source all i386
Version: 1.0.9+svn20040120-2
Distribution: unstable
Urgency: low
Maintainer: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Changed-By: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Description: 
 jikes-sablevm - Wrapper for jikes using classes from SableVM JVM
 libsablevm1 - Free implementation of JVM second edition - library
 libsablevm1-dev - Free implementation of JVM secon edition - development files
 sablevm    - Free implementation of Java Virtual Machine (JVM) second edition
Changes: 
 sablevm (1.0.9+svn20040120-2) unstable; urgency=low
 .
   * Added jikes-sablevm wrapper which was finally removed from jikes
     source package.
   * No, we don't provide java2-runtime. Yet ;-)
Files: 
 f8952c7e637eaed31f6059b2125a24fe 879 interpreters optional sablevm_1.0.9+svn20040120-2.dsc
 782568894c0ccf70de5d51dbf9a89691 808903 interpreters optional sablevm_1.0.9+svn20040120-2.tar.gz
 9ef6d5e09adbbaaa05bf5253177d1b27 33720 interpreters optional sablevm_1.0.9+svn20040120-2_i386.deb
 eb31483d96e7194ee0d065b0f324c68c 155426 libs optional libsablevm1_1.0.9+svn20040120-2_i386.deb
 b40e16cbbd187c781d4eb171d8378b44 23172 libdevel optional libsablevm1-dev_1.0.9+svn20040120-2_all.deb
 ecb7c35ba9a662cb151bd6ba9baf4664 18080 devel optional jikes-sablevm_1.0.9+svn20040120-2_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAEK/3cxjwiKS4/ekRAgf0AJ4jFJwn8gJxqH61efX1w2VAIGMgmACgpB4G
FNEiRF8ebb+lS5ERSPEOp6U=
=P9Je
-----END PGP SIGNATURE-----


Accepted:
jikes-sablevm_1.0.9+svn20040120-2_all.deb
  to pool/main/s/sablevm/jikes-sablevm_1.0.9+svn20040120-2_all.deb
libsablevm1-dev_1.0.9+svn20040120-2_all.deb
  to pool/main/s/sablevm/libsablevm1-dev_1.0.9+svn20040120-2_all.deb
libsablevm1_1.0.9+svn20040120-2_i386.deb
  to pool/main/s/sablevm/libsablevm1_1.0.9+svn20040120-2_i386.deb
sablevm_1.0.9+svn20040120-2.dsc
  to pool/main/s/sablevm/sablevm_1.0.9+svn20040120-2.dsc
sablevm_1.0.9+svn20040120-2.tar.gz
  to pool/main/s/sablevm/sablevm_1.0.9+svn20040120-2.tar.gz
sablevm_1.0.9+svn20040120-2_i386.deb
  to pool/main/s/sablevm/sablevm_1.0.9+svn20040120-2_i386.deb

Re: [Sablevm-developer] summary of JGF benchmark problems

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

Grzegorz B. Prokopski wrote:

> W li=B6cie z pon, 02-02-2004, godz. 23:29, Chris Pickett pisze:=20
>=20
>>I'm also having problems in the switch interpreter on a uniprocessor=20
>>with the following benchmarks in the JGF suites:
>=20
>=20
> Do you mean that you encounter problems with these benchmarks
> using current staging version of SableVM? or your modified version?
>=20

With my (shouldn't be broken) merge of SableVM into the switch=20
interpreter.  You're right ... I should test this against a vanilla=20
staging ... but I'm pretty confident that I haven't actually made any=20
changes against the plain switch interpreter (all the spmt stuff is=20
#ifdef'd away).  And I don't really have time to do it just now (I have=20
just finished running all the benchmarks I have, started on Friday, and=20
they didn't even all terminate -- the overhead of my spmt thing is=20
incredible when it's not actually doing anything).

>=20
>>Anyway, I just thought I'd post a summary of the problems I've encounte=
red.
>=20
> Good! Though what do you plan to find solutions to them? ;-)

Well, I still need help (suggestions) with JGFSyncBench problem (I=20
believe there's some kind of multithreading bug lurking in SableVM).=20
But ... I can't really look into things much more right now, actually=20
(conference deadlines), so I thought I'd let other people know, in case=20
you're interested (you are, so it's good!).  I'm actually not going to=20
rely on JGF for submitted work because of these issues, but it doesn't=20
matter, because I'm not having problems with SPECjvm98 and JOlden.


>>If you're curious, and you want some (basic) scripts (that almost=20
>>definitely need modifying) to run these benchmarks, after extracting,=20
>>look in chris/sandbox/sablevm/src/spmt/benchmarks/ for transform_grande=
,=20
>>transform_thread_grande, run_grande, run_thread_grande, and=20
>>create_JGF_report.
>=20
> Just out of curiosity. All of these benchmarks are under LGPL and thus
> are in our SVN, right? (or have you obtained special permission?)

I didn't actually put the benchmarks in the repository.  You have to=20
download them from the JGF site.  They're distributed with source code,=20
but no special license info apart from standard copyright.  That said,=20
if you make a patch for a benchmark, I'm sure the authors would consider =

applying it.  I'm not sure why they're not (L)GPL'd, actually, but the=20
authors can probably tell you more.  I also have (again, very basic)=20
scripts to run other benchmarks, such as SPECjvm98, in that directory=20
(Bruno has a version packaged for Ashes2).  You'll see (it's barely=20
commented, but it's obvious from the scripts how to arrange things ...=20
you just unpack the tarballs into my benchmarks/ directory, into folders =

called "grande" and "thread_grande").

> Anyway - if these benchmarks fail on current staging then it'd
> definitely be something I'd like to add to the massive testing
> machinery I am working on/with right now. Well... in fact even if
> they dont I'd like to do it too.

They're also very performance oriented, with a focus on scientific=20
computing (I think).  The benchmarks in section1 of each suite are all=20
micro-benchmarks, reporting frequencies of various things, so you can=20
compare VM's (the switch interpreter does not look good against Sun's=20
interpreter-JIT).

Definitely worth downloading and playing around with, from a "make=20
SableVM robust and fast" point of view, more than the other benchmarks=20
suites I've been using.  I think you might have even more problems with=20
the inlined threading engine.

Cheers,
Chris

[Sablevm-developer] Re: Pushing newer SableVM to testing (current sarge version is broken)

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

W liście z pon, 02-02-2004, godz. 23:06, James Damour pisze: 
> Thanks for the reply.  If this is the umpteenth time you've made it, I
> apologize... I haven't been following Free Java for very long.
nope, not at all. thanks for the bugreport. I didn't realize sablevm
in testing broke.

> I am loath to pull from unstable, and I don't need a working SableVM for
> some time, so I'll simply wait for the next version to migrate to
> testing.  Thank you very much for your good work.  I'm looking forward
> to trying to use SableVM to run my project (MegaMek) on Debian.
cd /tmp
wget http://gadek.debian.net/sablevm-unofficial/sablevm-alldebs.tgz
tar zxvf ./sablevm-alldebs.tgz
dpkg -i *.deb

I looked at update excuses and estimate it will take *at least* a week
for new version to get in testing. Even if I set priority "high"
- it has to be built on all arches first. And even if autobuilders
do their work right - there are still some problems ex. w/ jikes.
Ah, and ftpmasters still hold sablevm in NEW now...

So you'd better try the above debs ;-)

Cheers,

				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