sablevm-developer — SableVM developer mailing list

Re: Great(?) idea [was: Re: [Sablevm-developer] Porting SableVM to ia64 done in 3 (lazy) hours]

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

On Fri, Oct 11, 2002 at 09:28:22PM +0200, Grzegorz Prokopski wrote:
> The question is mainly to Etienne...
> 
> Instead of doing 
> 
> static inline jboolean
> _svmh_compare_and_swap (volatile _svmt_word *pword, _svmt_word
> old_value,
...
> why not just use this construction:
> 
> #include <asm/system.h>
>       return (cmpxchg((pword), (old_value), (new_value)) == (old_value))
...

> We could have all Linux arches supported in 24 hours! ;-)
> Why shouldn't we use it?

As long as we add a "#ifdef LINUX" (or the equivalent), we could do it.

Is there an equivalent for "iflush()"?  Then we would get the
inline-threaded engine to work too... :)

Etienne


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

Re: [Sablevm-developer] Porting SableVM to ia64 done in 3 (lazy) hours

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

On Fri, Oct 11, 2002 at 08:33:07PM +0200, Grzegorz Prokopski wrote:
> Just wanted you to know, that "ia64" has been just added to the
> list of architectures supported by SableVM JVM, next to i386 and
> alpha.

Super!

We'll have to port the inline-threaded engine soon, too.  We can
probably start working on that when I am finished with the current
step: I am currently working on filling some "relflection" holes
(e.g. Class.getMethods(), etc.) to get "Ant" to work on SableVM.

> Thanks to Martin Schulze <jo...@in...> who installed 
> build deps on merulo.d.o and thanks to Bdale Garbee <bd...@ga...>
> who asissted the port and installed the packages right after
> they were ready.

Thanks a lot.

> "HelloWorld!" app started since the first kick.

I like to hear this ;-)

> Maybe it's time for new release? ;-)

How about a new release on Sunday?  I am leaving to Quebec city to
visit friends until then, so I won't have time to work tonight and
tomorrow.

Grzegorz, thanks a lot!

Etienne

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

[Sablevm-developer] Status question(s)

[Grzegorz P. <gr...@se...>]

Hi!

A couple of questions of "where are we" kind...

1. I have seen some PowerPC patches on this list.
I even can find some PowerPC bits of this kind:

static inline void
_svmf_iflush (_svmt_word *pword)
{
#if   defined(__powerpc__)

  __asm__ __volatile__ ("dcbst 0,%0; sync; icbi 0,%0; isync"::"r"
(pword));

#elif defined(__i386__)
  /* do nothing */
#else
#error
#endif
}

Questions:
What stops us from getting PowerPC port ready?
What about other arches?
Which ones should we handle here, in _svmf_iflush (spparently)?
Which ones surely don't need this special treatment?

2. There are still problems w/ -native build-depending on
itself. It's very annoying especially while porting to new arches
(bdale was extremly helpful here, as he first installed "bad" -native,
then I rebuilded -native and he installed "good" version).
Not to mention auto-builders which won't be able to build the
package for the first time on new architecture.

Questions:
Any ideas how to fix it?
Etienne - do you have plans to remove this issue?
If yes - when can it be expected to happen?

3. I was looking at all the special, architecture-dependant
stuff in sablevm (at those "bits" I'd better say).

It seems that almost all of this could be fully automated,
so that we didn't need to do anything or almost anything to
build it on any new Linux port. Test program I attached is one of
two approches, first which I _have_ done - was to use ./configure
script to detect right types for our sizes of data.

Questions:
Do you think is it worth the effort?
Are the architectures expected to differ in some other manners
which would make this "automation" unneeded?

4. What will be needed to get this "faster" threading engine
working on non-i386 arches? (where should I start?)

Best reagards

					Grzegorz B. Prokopski

Great(?) idea [was: Re: [Sablevm-developer] Porting SableVM to ia64 done in 3 (lazy) hours]

[Grzegorz P. <gr...@se...>]

Hi all!

The question is mainly to Etienne...

Instead of doing 

static inline jboolean
_svmh_compare_and_swap (volatile _svmt_word *pword, _svmt_word
old_value,
                        _svmt_word new_value)
{
#if defined (__i386__)
#if defined (__alpha__)
#if defined (__ia64__)
(about a dozen of lines for every arch)

why not just use this construction:

#include <asm/system.h>
      return (cmpxchg((pword), (old_value), (new_value)) == (old_value))
               
In the original (found there:
 http://www.mail-archive.com/ka...@ru.../msg02563.html )
there was <asm/atomic.h>, but the definition of cmpxchg seems
to reside in asm/system.h

I checked the existence of the definition on my i386 and on debian's
ia64 machines. I haven't compiled it yet though.

We could have all Linux arches supported in 24 hours! ;-)
Why shouldn't we use it?

Whaddayathink?

				GBP

[Sablevm-developer] Porting SableVM to ia64 done in 3 (lazy) hours

[Grzegorz P. <gr...@se...>]

Hi!

Just wanted you to know, that "ia64" has been just added to the
list of architectures supported by SableVM JVM, next to i386 and
alpha.

Thanks to Martin Schulze <jo...@in...> who installed 
build deps on merulo.d.o and thanks to Bdale Garbee <bd...@ga...>
who asissted the port and installed the packages right after
they were ready.

"HelloWorld!" app started since the first kick.

The diff is below, at the end of this amil I also inlined very
simple&small c app that helps a bit w/ porting. It may be not so
bad idea to have it in the sources.

Maybe it's time for new release? ;-)

Best regards

					Grzegorz B. Prokopski



--- ./sablevm-1.0.4/src/libsablevm/include/jni_system_specific.h       
2002-08-14 23:29:54.000000000 -0600
+++ ./sablevm-1.0.4-new/src/libsablevm/include/jni_system_specific.h   
2002-10-11 08:49:24.000000000 -0600
@@ -15,7 +15,7 @@
 
 /* ia64, alpha and i386 are identical here */
 
-#if ((defined (__alpha__) || defined (__i386__)) && defined (__GNUC__))
+#if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__))
&& defined (__GNUC__))
 
 #define JNICALL
 #define JNIEXPORT
@@ -38,3 +38,4 @@
 #endif
 
 #endif /* NOT SVM_JNI_SYSTEM_SPECIFIC_H */
+
--- ./sablevm-1.0.4/src/libsablevm/system.c     2002-08-18
23:16:06.000000000 -0600
+++ ./sablevm-1.0.4-new/src/libsablevm/system.c 2002-10-11
10:53:09.000000000 -0600
@@ -5,7 +5,7 @@
  * modification of SableVM.                                  *
  * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
 
-#if ((defined (__alpha__) || defined (__i386__)) && defined (__GNUC__))
+#if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__))
&& defined (__GNUC__))
 
 /*
 ----------------------------------------------------------------------
@@ -28,6 +28,8 @@
 
 #elif defined(__i386__)
   /* do nothing */
+#elif defined(__ia64__)
+  /* do nothing */
 #else
 #error
 #endif
@@ -99,6 +101,15 @@
 /* *INDENT-ON* */
 #endif
 
+#if (defined (__ia64__))
+#include <ia64intrin.h>
+
+  jboolean result;
+
+  result = __sync_bool_compare_and_swap (pword, old_value, new_value);
+
+#endif
+  
   return result ? JNI_TRUE : JNI_FALSE;
 }
 
--- ./sablevm-1.0.4/src/libsablevm/system.h     2002-08-14
23:29:54.000000000 -0600
+++ ./sablevm-1.0.4-new/src/libsablevm/system.h 2002-10-11
09:25:47.000000000 -0600
@@ -48,7 +48,7 @@
 
 */
 
-#if ((defined (__alpha__) || defined (__i386__)) && defined (__GNUC__))
+#if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__))
&& defined (__GNUC__))
 
 /* "inline" is now an official keyword since the latest C standard
(1999).
    So, it is a reasonable assuption to expect a target compiler to
@@ -88,6 +88,18 @@
 #define SVM_ALIGNMENT_POWER 3  /* 2 ^^ SVM_ALIGNMENT_POWER ==
SVM_ALIGNMENT */
 #define SVM_PAGE_SIZE 8192
 
+#elif defined (__ia64__)
+
+typedef _svmt_u64 _svmt_word;
+
+#define SVM_WORD_SIZE 8         /* size in bytes */
+#define SVM_WORD_BIT_COUNT 64   /* size in bits */
+  
+/* see comments at the head of this file */
+#define SVM_ALIGNMENT 8
+#define SVM_ALIGNMENT_POWER 3   /* 2 ^^ SVM_ALIGNMENT_POWER ==
SVM_ALIGNMENT */
+#define SVM_PAGE_SIZE 16384
+
 #endif
 
 /* FFI specific types */



The helper program is this:

gadek@merulo:~/sablevm/tests$ cat ./typesizes.c 
#include <unistd.h>

int main(void) {
	int i;
	
	printf("Size of char is %i\n", sizeof(char));
	printf("Size of short is %i\n", sizeof(unsigned short));
	printf("Size of int is %i\n", sizeof(int));
	printf("Size of long int is %i\n", sizeof(long int));
	printf("Size of long long int is %i\n", sizeof(long long int));
	printf("Size of float is %i\n", sizeof(float));
	printf("Size of double is %i\n", sizeof(double));
	printf("Size of void* is %i\n", sizeof(void*));

	i = getpagesize();
	printf("Size of page is %i\n", i);

	return 0;
}

Re: [Sablevm-developer] actual build failure not catched (sablevm-nativelib build dep on sablevm-nativelib)

[Grzegorz P. <gr...@se...>]

W li=B6cie z =B6ro, 11-09-2002, godz. 22:53, Grzegorz Prokopski pisze:=20
> Hi!
>=20
> I reported previously, that from sablevm-nativelib source some of the
> libs are not build sometimes. So I made two builds - one w/o
> old sablevm-native installed, one - with. And compared build
> outputs. Here's what I found:
[...]
> 2. Some neat trick like LD_LIBRARY_PATH set to directory w/ just builded
> libclasspath should be used (I'll try it in a minute) (btw. is it
> portable outside Linux/glibc? no I think)
> Maybe -L parameter usage would be wiser? Surely.
LD_LIBRARY_PATH tric didn't worked
I don't know autotools well enough (yet? ;-) to fix this myself.
They're just too auto-matic for me :-/

> Current situtation is that I need to have sablevm-nativelib installed=20
> to be able build new sablevm-nativelib which is unnacceptable.
Anyway I uploaded 1.0.4 version to unstable. sablevm went to queue/NEW
of course and will have to be processed by ftpmasters (hopefully).

Because of above bug sablevm-nativelib won't be properly build
by autobuilders, as it now build-depends on itself (it's sick, I told
you). The i386 version hovewer worked for me fully.

> PS: The problem with sablevm-n.e.w looking for libs in o.l.d versions
> if those o.l.d versions were installed during the build - seems to be
> on similar ground. It seem that sablevm checks in /usr/lib,
> /usr/lib/sablevm for versions first, instead of own build directories.
> ATM I need to build conflict w/ sablevm and build depend on
> libsablevm-native with specified version that coresponds to sablevm
> version.
I just added build-conflicts: sablevm to sablevm control file and it
seems to solve the issue, even if I'd rather call it a workaround.

Regards

						GBP

[Sablevm-developer] actual build failure not catched (sablevm-nativelib build dep on sablevm-nativelib)

[Grzegorz P. <gr...@se...>]

Hi!

I reported previously, that from sablevm-nativelib source some of the
libs are not build sometimes. So I made two builds - one w/o
old sablevm-native installed, one - with. And compared build
outputs. Here's what I found:

--- ./native-installed.out      2002-09-08 22:17:47.000000000 +0200
+++ ./native-uninstalled.out    2002-09-09 00:33:47.000000000 +0200

-/usr/bin/install -c .libs/libjava-io-1.0.4.soT
/home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-io-1.0.4.so
-(cd
/home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm && rm -f libjava-io.so && ln -s libjava-io-1.0.4.so libjava-io.so)
-/usr/bin/install -c .libs/libjava-io.lai
/home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-io.la
+/usr/bin/ld: cannot find -lclasspath
+collect2: ld returned 1 exit status
+libtool: install: error: relink `libjava-io.la' with the above command
before installing it
 libtool: install: warning: remember to run `libtool --finish
/usr/lib/sablevm'

-/usr/bin/install -c .libs/libjava-lang-1.0.4.soT
/home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-lang-1.0.4.so
-(cd
/home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm && rm -f libjava-lang.so && ln -s libjava-lang-1.0.4.so libjava-lang.so)
-/usr/bin/install -c .libs/libjava-lang.lai
/home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-lang.la
+/usr/bin/ld: cannot find -lclasspath
+collect2: ld returned 1 exit status
+libtool: install: error: relink `libjava-lang.la' with the above
command before installing it
 libtool: install: warning: remember to run `libtool --finish
/usr/lib/sablevm'

-/usr/bin/install -c .libs/libjava-net-1.0.4.soT
/home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-net-1.0.4.so
-(cd
/home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm && rm -f libjava-net.so && ln -s libjava-net-1.0.4.so libjava-net.so)
-/usr/bin/install -c .libs/libjava-net.lai
/home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-net.la
+/usr/bin/ld: cannot find -lclasspath
+collect2: ld returned 1 exit status
+libtool: install: error: relink `libjava-net.la' with the above command
before installing it
 libtool: install: warning: remember to run `libtool --finish
/usr/lib/sablevm'

Of course libclasspath is part of just built sablevm-nativelib and
in _no case_ should be looked for in /usr/lib !

So I suggest that:
1. Such errors should be catched as errors and not ignored - should stop
compilation
2. Some neat trick like LD_LIBRARY_PATH set to directory w/ just builded
libclasspath should be used (I'll try it in a minute) (btw. is it
portable outside Linux/glibc? no I think)
Maybe -L parameter usage would be wiser? Surely.

Current situtation is that I need to have sablevm-nativelib installed 
to be able build new sablevm-nativelib which is unnacceptable.

Tell me what you think.

						GBP

PS: The problem with sablevm-n.e.w looking for libs in o.l.d versions
if those o.l.d versions were installed during the build - seems to be
on similar ground. It seem that sablevm checks in /usr/lib,
/usr/lib/sablevm for versions first, instead of own build directories.
ATM I need to build conflict w/ sablevm and build depend on
libsablevm-native with specified version that coresponds to sablevm
version.

Re: [Sablevm-developer] trying to build w/ free-java-sdk (sablevm) - failure

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

Grzegorz Prokopski wrote:
>>You are free to do it, though.  getMethod (and/or? getDeclaredMethod) is already 
>>implemented, and can be used as inspiration.  Source file: 
>>sablevm-x.y.z/src/libsablevm/java_lang_Class.c .
> 
> I really took some time and digged into this.
> However it seems that it's beyond my current abilities.
> 
> Even if java specs are clear and this method doesn't look too
> complicated

It's not that simple, either.

> - I don't know sablevm internal construction well enough.
> Sablevm methods aren't really documented and it would be hard for
> me (read: time consuming) to learn them first then try to build
> this function. I don't have enough time right now :-/

Welcome to the club of busy people. :-)

> I think I'll focus on packaging for now as I haven't solved all the
> issues yet. Maybe your students would be interested in biteing it?

I think that waiting a couple of week for my schedule to be less full is the 
best you can hope for, unless somebody else on this list is interested to do it 
before then.

> btw: why is this called 'reflection' ?

Because the traditional "reflection" (the real thing, not the Java *very* 
limited library support for it) allows you to reflect into live objects and 
classes, in purely dynamic OO systems.  E.g. it allows you not only to "look" at 
the structure of classes and objects, but also to modify them *dynamically*, 
adding and removing fields and methods.

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

Re: [Sablevm-developer] trying to build w/ free-java-sdk (sablevm) - failure

[Grzegorz P. <gr...@se...>]

W li=B6cie z pi=B1, 06-09-2002, godz. 15:30, Etienne M. Gagnon pisze:=20
> Grzegorz Prokopski wrote:
> > *** Couldn't bind native method Java_java_lang_Class_getMethods ***
> > *** or Java_java_lang_Class_getMethods__ ***
> ...
> > java.lang.UnsatisfiedLinkError
> > 	at java.lang.Class.getMethods(Class.java)
> You are free to do it, though.  getMethod (and/or? getDeclaredMethod) is =
already=20
> implemented, and can be used as inspiration.  Source file:=20
> sablevm-x.y.z/src/libsablevm/java_lang_Class.c .

I really took some time and digged into this.
However it seems that it's beyond my current abilities.

Even if java specs are clear and this method doesn't look too
complicated - I don't know sablevm internal construction well enough.
Sablevm methods aren't really documented and it would be hard for
me (read: time consuming) to learn them first then try to build
this function. I don't have enough time right now :-/

I think I'll focus on packaging for now as I haven't solved all the
issues yet. Maybe your students would be interested in biteing it?
Given that they're able to talk w/ you directly, live - they're in
much better position to try.

Best regards

						GBP

btw: why is this called 'reflection' ?

Re: [Sablevm-developer] Problems with 1.0.3 - java/lang/UnsatisfiedLinkError

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

Grzegorz Prokopski wrote:
> my build procedure for all the packages is simple: 
> ./configure; make; make install 
> with options about where put what - that's all 
> no magic at all 

You're not giving any argument to "configure"?  This won't work unless you're 
installing into /usr/local.  This might be your problem.  "configure" must be 
given the exact installation directory names (try configure --help).

> 
> So where do these numbers come from then? 

From:

1) configure.ac
2) build[-*] scripts (variable VERSION)

and (as a consequence of the above 1 & 2):

3) files generated by autoconf/automake: [*/]Makefile.in configure
4) files generated by "configure": [*/]/Makefile

> I removed all *sablevm* packages from my system, rebuilded, installed
> and problem still looks the same. But that's false impression(!)
> Now it looks for *1.0.4* libs where it should and finds them...
> with one exception [1]:
>... 
> So now, having all sablevm (non-working) packages installed I rebuilded
> 'native'. Oh f*** - it worked! - libjava-lang-1.0.4.so has been created!
> 
> Of course after I install this new 'native' package - HelloWorld works
> well w/o any tricks.
> 
> What would you say to that?

Check your build procedures, in light of the above information.

> My first impression is that the build process is flawed somewhere, as
> such things NEVER should take place, or at least should be very clearly
> documented. I will workaround it by declaring bulid-conflicts of sablevm
> with all sablevm packages and by build-depending of 'native' on
> 'sablevm' source resulting packages (no cyclic-build-deps).

I thought automake/autoconf were pretty much standard GNU tools... The only 
SableVM specific stuff is the "build" script.  The remaining is more/less 
standard auto* stuff.

Of course, you must always restart with a *fresh* working directory.  If you had 
any leftover files from a previous installation (in your working directory), 
auto* tools might behave strangely.

> 
> So, I belive that it works in _your_ environment, but the bug is
> somewhere there - don't you think?

Maybe, but you haven't convinced me yet. :-)

> Now I am gonna fix 1.0.4 packages and upload them to NEW queue with
> the hope that ftpmasters will finally let it into the archive :-/

Don't forget to be very friendly with our great fiends the ftpmasters.  They 
like to feel important and respected... ;-)))

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

Re: [Sablevm-developer] Problems with 1.0.3 - java/lang/UnsatisfiedLinkError

[Grzegorz P. <gr...@se...>]

W li=B6cie z pi=B1, 06-09-2002, godz. 15:19, Etienne M. Gagnon pisze:=20
> The package version is managed by automake/autoconmf/build scripts.  Pres=
umably,=20
> you are not using an *unmodified* SableVM "build" script, so I guess your=
=20
> modified build procedure has some problems.
my build procedure for all the packages is simple:=20
./configure; make; make install=20
with options about where put what - that's all=20
no magic at all=20

> You *must* rebuild all 3 sablevm[-*-library] packages for every new Sable=
VM release.
oh, sure I did !

> The symbolic links are made in part by autoconf scripts and in part by th=
e=20
> "build" script.
> You are right on the fact that there is no version *embedded* into the so=
urce=20
> code: this is exactly what the author wanted, for easier maintenance. :)
So where do these numbers come from then?=20

I removed all *sablevm* packages from my system, rebuilded, installed
and problem still looks the same. But that's false impression(!)
Now it looks for *1.0.4* libs where it should and finds them...
with one exception [1]:

open("/usr/lib/sablevm/libjava-lang-1.0.4.so", O_RDONLY) =3D -1 ENOENT (No
such file or directory)

How is that possible? don't know. But in just builded source tree I
don't find this file anymore (but it exists in builded 1.0.3 source
tree).

So now, having all sablevm (non-working) packages installed I rebuilded
'native'. Oh f*** - it worked! - libjava-lang-1.0.4.so has been created!

Of course after I install this new 'native' package - HelloWorld works
well w/o any tricks.

What would you say to that?

My first impression is that the build process is flawed somewhere, as
such things NEVER should take place, or at least should be very clearly
documented. I will workaround it by declaring bulid-conflicts of sablevm
with all sablevm packages and by build-depending of 'native' on
'sablevm' source resulting packages (no cyclic-build-deps).

So, I belive that it works in _your_ environment, but the bug is
somewhere there - don't you think?

Now I am gonna fix 1.0.4 packages and upload them to NEW queue with
the hope that ftpmasters will finally let it into the archive :-/

Cheers

						GBP

[1] I was building all 3 sources in separate directiries, simultanously
w/o having any sablevm binary/resulting package installed.

Re: [Sablevm-developer] trying to build w/ free-java-sdk (sablevm) - failure

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

Grzegorz Prokopski wrote:
> *** Couldn't bind native method Java_java_lang_Class_getMethods ***
> *** or Java_java_lang_Class_getMethods__ ***
...
> java.lang.UnsatisfiedLinkError
> 	at java.lang.Class.getMethods(Class.java)
...
> It seems that java.lang.Class.getMethods(Class.java) is having some
> problems. Is this GNU Classpath problem of SableVM's?

Ant does some pretty heavy use of reflection.  You can look at the API 
specification of java.lang.Class.getMethods() [in any recent API specification 
of Java], and you'll see what should be returned by this method.  You are 
invited to implement it, if you want...  [I thought I had already said all this 
in a previous message.]

Reflection is the responsibility of the VM, so, yes , it is a missing native 
method in SableVM.  As I said earlier, I am in my first teaching week, so don't 
count on me to implement it (and the upcoming many reflection methods in the Ant 
source code that follows the call to getMethods()) before a couple of weeks.

You are free to do it, though.  getMethod (and/or? getDeclaredMethod) is already 
implemented, and can be used as inspiration.  Source file: 
sablevm-x.y.z/src/libsablevm/java_lang_Class.c .

The type structures are defined in sablevm-x.y.z/src/libsablevm/types.h .

I know you'd like it working *now*, but *I* do not have time just *now*. :(

Have fun!

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

Re: [Sablevm-developer] Problems with 1.0.3 - java/lang/UnsatisfiedLinkError

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

Hi Grzegorz,

Grzegorz Prokopski wrote:
> Hi!
> 
> I am back from (longer) vacations. I packaged sablevm 1.0.4.
> 
> Just for the record - "it" happens in 1.0.4 version too.
> 
> But I think I may now know what's happening.
> After installing 1.0.3 I strace shows things like this:
> 
> open("/usr/lib/sablevm/libclasspath-1.0.1.so", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> 
> Note 1.0.1 number there! - no such file exists!
> 
> When I am trying to use 1.0.4 it searches for libclasspath-1.0.3.so
> and other *1.0.3* files which don't exist!
> 
> The question now is: am *I* messing sth? I couldn't find any "1.0.3"
> string in sources of nativelib or sablevm. Anyway - the facts I can
> observe are above.
> 
> Hits?

The package version is managed by automake/autoconmf/build scripts.  Presumably, 
you are not using an *unmodified* SableVM "build" script, so I guess your 
modified build procedure has some problems.

You *must* rebuild all 3 sablevm[-*-library] packages for every new SableVM release.

The symbolic links are made in part by autoconf scripts and in part by the 
"build" script.

You are right on the fact that there is no version *embedded* into the source 
code: this is exactly what the author wanted, for easier maintenance. :)

Etienne

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

[Sablevm-developer] trying to build w/ free-java-sdk (sablevm) - failure

[Grzegorz P. <gr...@se...>]

Hi!

As I got 1.0.4 working (w/ 1.0.3 symlinks as I described in my other
mail) - I wanted to try ant compilation.

here's the output:

greg@greg:/opt/media/build/ant-1.5$ dpkg-buildpackage -rfakeroot
dpkg-buildpackage: source package is ant
dpkg-buildpackage: source version is 1.5-1
dpkg-buildpackage: source maintainer is Stefan Gybas <sg...@de...>
dpkg-buildpackage: host architecture is i386
 fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -rf build build-stamp
dh_clean
 dpkg-source -b ant-1.5
dpkg-source: building ant using existing ant_1.5.orig.tar.gz
dpkg-source: building ant in ant_1.5-1.diff.gz
dpkg-source: warning: ignoring deletion of file
src/main/org/apache/tools/ant/taskdefs/email/Message.java.rej
dpkg-source: warning: ignoring deletion of file
src/main/org/apache/tools/ant/taskdefs/email/Message.java.orig
dpkg-source: warning: ignoring deletion of file
docs/manual/CoreTasks/mail.html.orig
dpkg-source: building ant in ant_1.5-1.dsc
 debian/rules build
dh_testdir
/bin/sh bootstrap.sh
... Bootstrapping Ant Distribution
... Compiling Ant Classes
... Copying Required Files
... Building Ant Distribution
/usr/lib/fjsdk/bin/java -classpath
build/classes:src/main::/usr/share/java/antlr.jar:/usr/share/java/bsf.jar:/=
usr/share/java/junit.jar:/usr/share/java/log4j.jar:/usr/share/java/oro.jar:=
/usr/share/java/regexp.jar:/usr/share/java/xalan2.jar:/usr/share/java/xerce=
sImpl.jar:/usr/share/java/xml-apis.jar:/usr/share/sablevm/classes -Dant.hom=
e=3D. org.apache.tools.ant.Main -emacs jars javadocs
Buildfile: build.xml
*** Couldn't bind native method Java_java_lang_Class_getMethods ***
*** or Java_java_lang_Class_getMethods__ ***

BUILD FAILED
java.lang.UnsatisfiedLinkError
	at java.lang.Class.getMethods(Class.java)
	at
org.apache.tools.ant.IntrospectionHelper.IntrospectionHelper(IntrospectionH=
elper.java:207)
	at
org.apache.tools.ant.IntrospectionHelper.getHelper(IntrospectionHelper.java=
:384)
	at org.apache.tools.ant.ProjectHelper.configure(ProjectHelper.java:296)
	at
org.apache.tools.ant.helper.ProjectHelperImpl$TaskHandler.init(ProjectHelpe=
rImpl.java:812)
	at
org.apache.tools.ant.helper.ProjectHelperImpl$ProjectHandler.handleProperty=
(ProjectHelperImpl.java:566)
	at
org.apache.tools.ant.helper.ProjectHelperImpl$ProjectHandler.startElement(P=
rojectHelperImpl.java:510)
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
Source)
	at
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
Source)
	at org.apache.xerces.impl.XMLNamespaceBinder.emptyElement(Unknown
Source)
	at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unkn=
own Source)
	at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispat=
cher.dispatch(Unknown Source)
	at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown =
Source)
	at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
	at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at
org.apache.tools.ant.helper.ProjectHelperImpl.parse(ProjectHelperImpl.java:=
155)
	at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:117)
	at org.apache.tools.ant.Main.runBuild(Main.java:597)
	at org.apache.tools.ant.Main.start(Main.java:196)
	at org.apache.tools.ant.Main.main(Main.java:235)
	at java.lang.VirtualMachine.invokeMain(VirtualMachine.java)
	at java.lang.VirtualMachine.main(VirtualMachine.java:88)

Total time: 15 seconds
java.lang.UnsatisfiedLinkError
	at java.lang.Class.getMethods(Class.java)
	at
org.apache.tools.ant.IntrospectionHelper.IntrospectionHelper(IntrospectionH=
elper.java:207)
	at
org.apache.tools.ant.IntrospectionHelper.getHelper(IntrospectionHelper.java=
:384)
	at org.apache.tools.ant.ProjectHelper.configure(ProjectHelper.java:296)
	at
org.apache.tools.ant.helper.ProjectHelperImpl$TaskHandler.init(ProjectHelpe=
rImpl.java:812)
	at
org.apache.tools.ant.helper.ProjectHelperImpl$ProjectHandler.handleProperty=
(ProjectHelperImpl.java:566)
	at
org.apache.tools.ant.helper.ProjectHelperImpl$ProjectHandler.startElement(P=
rojectHelperImpl.java:510)
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
Source)
	at
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
Source)
	at org.apache.xerces.impl.XMLNamespaceBinder.emptyElement(Unknown
Source)
	at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unkn=
own Source)
	at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispat=
cher.dispatch(Unknown Source)
	at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown =
Source)
	at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
	at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at
org.apache.tools.ant.helper.ProjectHelperImpl.parse(ProjectHelperImpl.java:=
155)
	at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:117)
	at org.apache.tools.ant.Main.runBuild(Main.java:597)
	at org.apache.tools.ant.Main.start(Main.java:196)
	at org.apache.tools.ant.Main.main(Main.java:235)
	at java.lang.VirtualMachine.invokeMain(VirtualMachine.java)
	at java.lang.VirtualMachine.main(VirtualMachine.java:88)
... Failed Building Ant Distribution !
make: *** [build-stamp] B=B3=B1d 1

It seems that java.lang.Class.getMethods(Class.java) is having some
problems. Is this GNU Classpath problem of SableVM's?

						GBP

PS: It seems that ant maintainer is looking for free, properly licensed,
working environment to build free ant. If SableVM could jump in as the
JVM w/ which ant is build - it should prove SableVM to be really useful
and gain us some more users (what rather means: developers ATM).
PSS: If anyone want to try building ant - I'll put up my slightly
modified source somewhere.

Re: [Sablevm-developer] Problems with 1.0.3 - java/lang/UnsatisfiedLinkError

[Grzegorz P. <gr...@se...>]

W li=B6cie z wto, 20-08-2002, godz. 16:41, Grzegorz Prokopski pisze:=20
> Hi!
>=20
> I updated debian packages to 1.0.3 version and now I am unable
> to run even HelloWorld.jar.
>=20
> Short output is this:
>=20
> greg@greg:~$ java -jar HelloWorld.jar=20
> /usr/bin/sablevm -Y --classpath=3DHelloWorld.jar: HelloWorld
> java/lang/UnsatisfiedLinkError
Hi!

I am back from (longer) vacations. I packaged sablevm 1.0.4.

Just for the record - "it" happens in 1.0.4 version too.

But I think I may now know what's happening.
After installing 1.0.3 I strace shows things like this:

open("/usr/lib/sablevm/libclasspath-1.0.1.so", O_RDONLY) =3D -1 ENOENT (No
such file or directory)

Note 1.0.1 number there! - no such file exists!

When I am trying to use 1.0.4 it searches for libclasspath-1.0.3.so
and other *1.0.3* files which don't exist!

The question now is: am *I* messing sth? I couldn't find any "1.0.3"
string in sources of nativelib or sablevm. Anyway - the facts I can
observe are above.

Hits?

						GBP

PS: Gotta go out for a few hours now so I didn't do any extensive
testing. But one thing I can tell you. If I install 1.0.4 and
symlink all /usr/lib/sablevm/*1.0.4* to /usr/lib/sablevm/*1.0.3*
names - "HelloWorld" works!

Re: [Sablevm-developer] Another small step on powerpc

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

Hi Mark,

Interesting discovery.  Read comments below.

On Sun, Aug 25, 2002 at 08:52:43PM +0200, Mark Wielaard wrote:
> I can now run Hello World out of the box without patching
> FileIn/Outputstream and from the normal user classpath
> (including from jar files)!
> 
> The problem is in native.c (and clearly marked as such...)
> 
> @@ -1241,7 +1241,10 @@
>        case SVM_TYPE_BOOLEAN:
>  	{
>  	  /* don't forget about little/big endian alignment */
> -	  params[0].jint = *((jboolean *) &result[0]);

I don't see what's wrong in that code (maybe I'm blind too;-).  The
call to ffi_call() was given a pointer to a location to store the
result value.  The pointer (seen by ffi_call as (void *)) was
&result[0].  "Previously" ffi_prep_cif() told the ffi library that
this pointer would be a pointer to a "jboolean" variable to hold the
jboolean return value.  So, at first glance, this code seems correct,
to me.

Now, reading the /usr/share/doc/libffi2/README file, I noticed that
there are potential problems on the PPC.  These problems seemed
related to structures, not to primitive type values, though.

Maybe I am missing something?...  Probably doing PPC libffi tests
would be the right thing to do, but I do not have time, just now;-)

Thanks for your work!

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

[Sablevm-developer] Another small step on powerpc

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

Hi,

I can now run Hello World out of the box without patching
FileIn/Outputstream and from the normal user classpath
(including from jar files)!

The problem is in native.c (and clearly marked as such...)

@@ -1241,7 +1241,10 @@
       case SVM_TYPE_BOOLEAN:
 	{
 	  /* don't forget about little/big endian alignment */
-	  params[0].jint = *((jboolean *) &result[0]);
+          if (&result[0] == 0)
+	    params[0].jint = 0;
+          else
+            params[0].jint = 1;
 	  frame->stack_size++;
 	}

There are more places in that file that seem to need adaption for
powerpc but this one fixed the FileDescriptor problem I was seeing.

Cheers,

Mark

Re: [Sablevm-developer] Jikes 1.16 bug on FreeBSD-stable

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

On Sat, Aug 24, 2002 at 10:53:55AM -0700, Archie Cobbs wrote:
> FYI-
> 
> There is a core dump bug with jikes on FreeBSD-stable that needs
> to be fixed before the SableVM classes will compile. This means the
> FreeBSD port is broken on -stable.

Jikes 16 brokennes is Documented in the README.  Apparently Jikes 1.16
CVS has some bug fixes, but I strongly suggest sticking to 1.15 until
Jikes releases a *truely* stable version.

Jikes 1.16 generates broken bytecode which can cause random problems
in any VM that does not have a verifier.

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

[Sablevm-developer] Jikes 1.16 bug on FreeBSD-stable

[Archie C. <ar...@de...>]

FYI-

There is a core dump bug with jikes on FreeBSD-stable that needs
to be fixed before the SableVM classes will compile. This means the
FreeBSD port is broken on -stable.

If any C++ experts out there want to help (I know nothing about C++),
please take a look...

  http://www.freebsd.org/cgi/query-pr.cgi?pr=41961

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

Re: [Sablevm-developer] Problems with 1.0.3 - java/lang/UnsatisfiedLinkError

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

Mark Wielaard wrote:
 > This seems to be it!
...
  > mark@multatuli:~$ /usr/local/sablevm/bin/sablevm-debug -Y Hello
  > Hello World!
  >
  > Yeah! If "Hello World" is possible everything else should be possible :)

This is great news!

As for the --classpath thing: SableVM uses a Java class loader to load 
application classes.  More precisely, the starting point is the 
java.lang.VirtualMachine class which indirectly invokes the system class loader. 
  The system class loader is the gnu.java.lang.SystemClassLoader class.

It is often useful to print debug messages to identify problems, yet, in the 
VM's class library, invoking System.out.println() has MANY side effects, by 
potentially changing dramatically the flow of control (due to all the class 
loading and initialization it causes).

For this reason, you will find very convenient "print" methods in the 
java.lang.VirtualMachine class.  If you need them for debugging code in other 
packages (e.g. java.io.*), you will need to temporarily make the VirtualMachine 
class "public".

Have fun!

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

Re: [Sablevm-developer] wanted to try AWT - failure report

[John L. <je...@pi...>]

You're right,

it might have been different a while back.

John Leuner


On Tue, 2002-08-20 at 21:53, Archie Cobbs wrote:
> John Leuner writes:
> > Have you built that library?
> > 
> > You need to build classpath with:
> > 
> > configure --enable-gtk-peers
> 
> According to sablevm-native-library-1.0.3/classpath-docs/INSTALL,
> it's "--enable-gtk-peer" and that's the default; you must specify 
> "--disable-gtk-peer" to disable it.
> 
> In any case, it appears to me that ./configure completely ignores
> this flag anyway.
> 
> -Archie
> 
> __________________________________________________________________________
> Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

[Sablevm-developer] Re: sablevm_1.0.1-4_i386.changes REJECTED

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

W li=B6cie z czw, 22-08-2002, godz. 00:17, James Troup pisze:=20
> Hi,
> =20
>  Your lib and dev package look a little wacky, as in the -dev package
>  doesn't contain much.  lintian says:
> =20
>  W: libsablevm1: non-dev-pkg-with-shlib-symlink usr/lib/libsablevm.so.1.0=
.1 usr/lib/libsablevm.so
> =20
>  Also, lintian is whining about duplicate license files.  Please fix
>  the latter and the former (or explain what I'm missing).

I uploaded new version. Changelog below explains everything.

sablevm (1.0.1-5) unstable; urgency=3Dlow

  * Trying again. Closes: #156019
  * moved .so library symlink and .la file to -dev package
  * note to ftpmaster: -dev is needed because /usr/include/*.h files
    conflict with some other (entire) JVMs in Debian and I don't want
    sablevm to conflict with them
  * note to ftpmaster: extra licenses in /usr/share/sablevm are used by
    sablevm binary to display licensing and authors informations -
    that's author's explict wish to have it this way (instead of for
    ex. hardcoded in binary); as /usr/share/sablevm/COPYING.LIB is the
    same as /usr/share/common-licenses/LGPL-2.1 - I symlinked them
  * note to ftpmaster: having separate libsablevm package was proposed
    by upstream, discussed and agreed as The Right Thing(tm)
  * note to ftpmaster: if you have some other technical problems with
    this package - please file a bugreport or just mail me; I'll
    explain/fix remaining isses ASAP; rejecting the package worries me
    and I am afraid if it won't make it waiting another week for
    acceptance. thank you for your understanding

 -- Grzegorz Prokopski (Debian Developer) <ga...@de...>  Thu, 22
Aug 2002 03:46:50 +0200

Regards

					Grzegorz B. Prokopski

Re: [Sablevm-developer] Problems with 1.0.3 - java/lang/UnsatisfiedLinkError

[Grzegorz P. <gr...@se...>]

W li=B6cie z czw, 22-08-2002, godz. 00:52, Mark Wielaard pisze:=20
> I haven't yet figured out why that is but this is progress. And when I
> copy Hello.class to /usr/local/sablevm/lib/sablevm/classes-1.0.1/
> I get:
> mark@multatuli:~$ /usr/local/sablevm/bin/sablevm-debug -Y Hello
> Hello World!
Congrats!!!

> Yeah! If "Hello World" is possible everything else should be possible :)
Yes, that means we're "almost there" (-:

Huh, I think in such way we'll have 12 architectures by the end of this
year very easily. I think everybody understand, that this would be major
step towards wider acceptance of sablevm as "The Free JVM".

> I am very happy because this means that there might be some issues on
> PowerPC but it seems there is not something major wrong.
Yeah - I was worried a bit about PowerPC being hi-endian, but now you
prove my worries to be unnecessary ;-)

> Hopefully I will have some time this weekend to clean up what I have and
> look at where/why the valid() really fails and why my sablevm cannot
> find anything besides inside its own bootclasspath directory.
I hope debian admins will finally install those -dev packages I asked
for ;-) It takes them forever to do this. If it's like this for longer
time - I'll compile and install them in my home dir, but that's
hackish and errorprone.

Today sablevm-classlib and sablevm-nativelib were accepted into archive,
but unfortunatelly I overlooked some bit in sablevm and it got rejected
(first time in my history) so it will take a moment longer.
Anyway - it seems that the porting effort can be made a bit more
"blindly" - the we can go by simply uploading "blindly ported" packages,
letting autobuilders play with them and waiting for bugreports.
We'll see.

Summarizing: WoW! - thanks for the happy news!

Best regards

					GBP

Re: [Sablevm-developer] Problems with 1.0.3 - java/lang/UnsatisfiedLinkError

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

Hi,

On Wed, 2002-08-21 at 18:30, Mark Wielaard wrote:
> 
> I didn't have time to recompile and do the next steps but from the
> output I suspect the following piece of code in java.io.FileInputStream:
> 
>     public
>     FileInputStream(FileDescriptor fd) throws SecurityException
>     {  
>       // Hmmm, no other exception but this one to throw, but if the
>     descriptor
>       // isn't valid, we surely don't have "permission" to read from it.
>       if (!fd.valid())
>         throw new SecurityException("Invalid FileDescriptor");
>     

This seems to be it!
After I just commented out that part and recompiled I got:

mark@multatuli:~$ /usr/local/sablevm/bin/sablevm-debug -Y Hello
java.lang.ClassNotFoundException: Hello
 at gnu.java.lang.SystemClassLoader.findClass(SystemClassLoader.java:73)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:259)
 at java.lang.VirtualMachine.main(VirtualMachine.java:79)

I haven't yet figured out why that is but this is progress. And when I
copy Hello.class to /usr/local/sablevm/lib/sablevm/classes-1.0.1/
I get:

mark@multatuli:~$ /usr/local/sablevm/bin/sablevm-debug -Y Hello
Hello World!

Yeah! If "Hello World" is possible everything else should be possible :)

I am very happy because this means that there might be some issues on
PowerPC but it seems there is not something major wrong.

Hopefully I will have some time this weekend to clean up what I have and
look at where/why the valid() really fails and why my sablevm cannot
find anything besides inside its own bootclasspath directory.

Good night,

Mark

Re: [Sablevm-developer] Problems with 1.0.3 - java/lang/UnsatisfiedLinkError

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

Hi,

On Wed, 2002-08-21 at 17:11, Etienne M. Gagnon wrote:
> The fist thing we want to do it to locate the problem more precisely,
> using sablevm-debug.  So, here are 3 things to do:
> 
> 1- Run:
> 
> $ sablevm-debug -p "sablevm.verbose.methods" HelloWorld 2>&1 | tail -1000 > output-methods.txt

The actual command I ran was:
/usr/local/sablevm/bin/sablevm-debug -p "sablevm.verbose.methods=true" \
  Hello 2>&1 | tail -5000 > output-methods.txt

> 2- Run:
> 
> $ sablevm-debug -p "sablevm.verbose.methods" -p "sablevm.verbose.instructions" HelloWorld 2>&1 | tail -1000 > output-instructions.txt

/usr/local/sablevm/bin/sablevm-debug -p "sablevm.verbose.methods=true" \
  -p "sablevm.verbose.instructions=true" Hello 2>&1 | tail -10000 >
output-instructions.txt

I didn't have time to recompile and do the next steps but from the
output I suspect the following piece of code in java.io.FileInputStream:

    public
    FileInputStream(FileDescriptor fd) throws SecurityException
    {  
      // Hmmm, no other exception but this one to throw, but if the
    descriptor
      // isn't valid, we surely don't have "permission" to read from it.
      if (!fd.valid())
        throw new SecurityException("Invalid FileDescriptor");
    

Does that make sense to you? Hopefully I can send more data later.
(But it might not be till tomorrow).

Cheers,

Mark