sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] reflection methods

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

Hello,

I got several methods somewhat working and I also came up with
questions/issues.=20

Here are the first few:

1) All the native Class methods: Class.m(JNIEnv *_env, jobject
this) already implemented does a segmentation fault at:

_svmt_type_info *type =3D _svmf_unwrap_class_instance (env, this)

if the Class object represents a primitive (ex: int.class).

Example: int.class.getSuperclass() (but it applies to several) crashes
instead of returning null.  (Note: getSuperclass() has other bugs, but I
fixed them.).

I am fixing this by simply checking if it represents a primitive type in
Class.java and calling the native function only if does not.  This
avoid "switching" to native mode for primitive types.  I am not
sure if _svmf_unwrap_class_instance was designed with that assumption
in mind or if this is a bug.

2) I changed one of the native declaration:

from:
JNIEXPORT jint JNICALL Java_java_lang_reflect_Method_getModifiers(JNIEnv
*, jobject);
to:
JNIEXPORT jint JNICALL
Java_java_lang_reflect_Method_nativeGetModifiers(JNIEnv *, jclass,
jbyteArray);

This makes it look similar in prototype to the others and simplifies the
implementation.

This may be a Classpath bug.



David


On Sun, Jan 26, 2003 at 10:55:28AM -0500, David Paul BELANGER wrote:
>=20
> Hello,
>=20
> I volunteered to help implement the native methods in the reflection
> classes (java.lang.Class and classes in java.lang.reflect).
> These include methods such as Class.getMethods() that have
> been asked a few times on this list.
>=20
> My short term goal is to implement enough methods to run Ant and JUnit
> as soon as possible.
>=20
> I have a partially working getMethods().  I will made my code public as
> soon as a have a reasonable set of working functions.
>=20
>=20
> David
>=20
>=20
> ---
>=20
> David B=E9langer
> Graduate Student
> School of Computer Science
> McGill University
> Office: MC226
>=20
> Web page:   http://www.cs.mcgill.ca/~dbelan2/
> Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware=
.com
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
--=20

---

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

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

[Sablevm-developer] reflection methods

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

Hello,

I volunteered to help implement the native methods in the reflection
classes (java.lang.Class and classes in java.lang.reflect).
These include methods such as Class.getMethods() that have
been asked a few times on this list.

My short term goal is to implement enough methods to run Ant and JUnit
as soon as possible.

I have a partially working getMethods().  I will made my code public as
soon as a have a reasonable set of working functions.


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] Re: UnsatisfiedLinkError help

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

W li=B6cie z =B6ro, 22-01-2003, godz. 15:58, Grzegorz B. Prokopski pisze:=20
> I must say I tried to look into this problem some time ago,
> W li=B6cie z pon, 20-01-2003, godz. 17:09, Ben Burns pisze:=20
> > might be interested in the problem anyway.  Where would be the best pla=
ce to=20
> > log a bug?   If you want please let me know where I should start if I h=
ave to=20
> > code anything (I believe the code must already exist though).
Here are some pointers, as good as my knowledge permits.

in ./src/libsablevm/java_lang_Class.c
There should be definition like this:
(I belive it fits below nativeGetMethod code in this file)

/*
----------------------------------------------------------------------
Java_java_lang_Class_nativeGetMethods
----------------------------------------------------------------------
*/

/*
 * Class:     java_lang_Class
 * Method:    nativeGetMethods
 * Signature:
([BLjava/lang/String;Ljava/lang/String;)Ljava/lang/reflect/Methods;
 */

JNIEXPORT jobjectArray JNICALL
Java_java_lang_Class_nativeGetMethods (JNIEnv *_env, jclass _class,
					jbyteArray vmData)
{


}

I looked for an inspiration in nativeGetMethod and I think there
are many things I don't know:
1. How to enumerate methods available in the class?
(GetMethod asks for a specific method which name and parameters
types are provided by the user/programmer)
Oh, and we should do it including same methods w/ different params.
2. How to return an array of classes?
(None of the methods in this file returns array, so some idea on
how to compose array of methods having method classes would be=20
helpful).
3. What does the part between /* wrap it */ and end: do?

I imagine pseudocode for the function this way:

ret_array =3D NULL; no =3D 0;
for (method in get_class_methods(class))
  for (param_set in get_param_sets(method))
    if is_public (method, param)
      ret_array[no++] =3D resolve(method, param)
return ret_array;

(why ain't the real code as easy to write as pseudo-code? ;-)

Can somebody enlighten me a bit?

I'd really like to learn some more about SableVM internals and
I belive giving some informations like those publicly - will
benefit future contribution.

At least until we get "SableVM hacking guide" ;-)

Regards

				Grzegorz B. Prokopski

PS: Ben, if you're considering contribution to SableVM
(which is very welcomed of course) - you could subscribe to
at least sablevm-developer mailing list at www.sablevm.org.

--=20
Grzegorz B. Prokopski <ga...@de...>
Debian http://www.debian.org/

[Sablevm-developer] Re: UnsatisfiedLinkError help

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

Hi!

Sorry for late response.
Thanks for choosing free-java-sdk to do your work!

Now - about your problem w/ SableVM:
Unfortunatelly getMethods is not yet implemented.
It also keeps things like ant from building properly, so there's
hope that it'll be fixed in not too distant future.

I must say I tried to look into this problem some time ago, but
I didn't go beyond looking at documentation and adding empty stub.
The description of needed functionality is here:
http://java.sun.com/j2se/1.3/docs/api/java/lang/Class.html#getMethods()
I am thus Cc:ing SableVM-devel ML - maybe someone could pick this
problem up?

Cheers,

				Grzegorz B. Prokopski

W li=B6cie z pon, 20-01-2003, godz. 17:09, Ben Burns pisze:=20
> Hello Grzegorz,
>=20
> Firstly, thank you for your effort in putting together the free-java-sdk =
=20
> package.  I am a Java developer, but would like my code to ebe ligible fo=
r=20
> inclusion in debian main, obviously your package is the path I should tak=
e to=20
> get there.
>=20
> As part of my latest work, I have devloped a small component based framew=
ork=20
> for Java applications that I call jconfig.  It uses property files to loa=
d=20
> and initialise java beans, and uses the the Class.getMethods() method to=20
> determine which method to call to set property values.  This works fine w=
ith=20
> Sun's JDK, but I get the following error running it with sablevm:
>=20
> *** 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)
> 	at jconfig.Nucleus.initialiseComponent(Nucleus.java:148)
> 	at jconfig.Nucleus.resolveComponentFromPropertiesFile(Nucleus.java:58)
> 	at jconfig.Nucleus.resolveComponent(Nucleus.java:34)
> 	at jconfig.Nucleus.loadInitialServices(Nucleus.java:273)
> 	at jconfig.Nucleus.main(Nucleus.java:312)
> 	at java.lang.VirtualMachine.invokeMain(VirtualMachine.java)
> 	at java.lang.VirtualMachine.main(VirtualMachine.java:88)
>=20
> I ran #nm -dynamic libjava-lang.so, in /usr/lib/sablevm, where I expected=
 to=20
> find Java_lang_Class_getMethods, but it is not defined there.  I'm a bit=20
> surprised that this doesn't work.
>=20
> I''m not sure you are the right person to contact for this problem, but=20
> thought you could point me in the right direction.  I also thought that y=
ou=20
> might be interested in the problem anyway.  Where would be the best place=
 to=20
> log a bug?   If you want please let me know where I should start if I hav=
e to=20
> code anything (I believe the code must already exist though).
>=20
> If you want a copy of my code, please ask.
>=20
> Thanks again,
> Regards,
> Ben
--=20
Grzegorz B. Prokopski <ga...@de...>
Debian http://www.debian.org/

Re: [Sablevm-developer] native libs

[Prof. E. M. G. <eti...@uq...>]

Hi David.

I had identified the problem yesterday, and I fixed it this morning.

Simply check-out the CVS version.

Etienne

David Paul BELANGER wrote:
> I was able to fix it.  I was confused for quite some time by a pointer
> getting "magically" the value NULL.
>=20
>>From my understanding there is a bootstrap class loader and
> "application" class loader(s).  The native library list in the applicat=
ion
> class loader is initially NULL.  The code in
> java_lang_Runtime_nativeLoad does not check if the list is initially
> NULL.  The bootstrap class loader library happened not to be initially
> null since is
> it is initialized early with sablevm itself elsewhere.
>=20
> I will clean up my code and send a patch via the bug tack system.
>=20
>=20
> David
>=20
> On Mon, Jan 20, 2003 at 04:21:01PM -0500, Prof. Etienne M. Gagnon wrote=
:
>=20
>>OK.  I'm back!  :-)
>>
>>I'll look at this tomorrow.  You're on Debian/x86, right?
>>
>>Etienne
>>
>>David Paul BELANGER wrote:
>>
>>>Hi,
>>>
>>>I'm getting a segmentation fault when trying to load a native library.=

>>>The system native library (libjava-lang, libjava-io) get properly load=
ed
>>>but when it comes to mine, it seems that the pointer passed to the
>>>memory allocator is null.  My library seems to get properly loaded (th=
e
>>>handle is non-null).
>>>
>>>I have included some gdb output and a simple Hello program that cause
>>>the error.
>>>
>>>Thanks,
>>>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
>>>
>>>
>>>
>>>----------------------------------------------------------------------=
--
>>>
>>>Program received signal SIGSEGV, Segmentation fault.
>>>[Switching to Thread 1024 (LWP 10068)]
>>>0x40029cbe in _svmf_cl_alloc (env=3D0x804d548, class_loader_info=3D0x8=
0636b8,=20
>>>   size=3D12, ptr=3D0x0) at class_loader_memory_manager.c:139
>>>139     class_loader_memory_manager.c: No such file or directory.
>>>       in class_loader_memory_manager.c
>>>(gdb) backtrace
>>>#0  0x40029cbe in _svmf_cl_alloc (env=3D0x804d548,=20
>>>class_loader_info=3D0x80636b8, size=3D12, ptr=3D0x0) at=20
>>>   class_loader_memory_manager.c:139
>>>#1  0x40029dd4 in _svmf_cl_zalloc (env=3D0x804d548,=20
>>>class_loader_info=3D0x80636b8, size=3D12, ptr=3D0x0) at=20
>>>   class_loader_memory_manager.c:181
>>>#2  0x4002aab2 in _svmh_cl_zalloc_native_library (env=3D0x804d548,=20
>>>   class_loader_info=3D0x80636b8, ptr=3D0x0) at cl_alloc.c:585
>>>#3  0x400890ea in Java_java_lang_Runtime_nativeLoad (_env=3D0x804d548,=
=20
>>>   this=3D0x8060028, _filename=3D0x8060610) at java_lang_Runtime.c:246=

>>>#4  0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
>>>#5  0x400df41a in ffi_call () from /usr/lib/libffi.so.2
>>>#6  0x400334f8 in _svmf_invoke_native_nonstatic (env=3D0x804d548) at=20
>>>native.c:1171
>>>#7  0x40071b53 in _svmf_interpreter (_env=3D0x804d548)
>>>   at instructions_switch.c:9839
>>>#8  0x40027270 in _svmh_invoke_specific_static_clinit (env=3D0x804d548=
,=20
>>>   method=3D0x4145046c) at method_invoke.c:5061
>>>#9  0x40088c9e in Java_java_lang_Class_step8 (_env=3D0x804d548,=20
>>>_class=3D0x805fd98, vmData=3D0x80607a0) at java_lang_Class.c:741
>>>#10 0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
>>>#11 0x400df41a in ffi_call () from /usr/lib/libffi.so.2
>>>#12 0x40032bf8 in _svmf_invoke_native_static (env=3D0x804d548) at=20
>>>native.c:834
>>>#13 0x40071aa4 in _svmf_interpreter (_env=3D0x804d548)
>>>   at instructions_switch.c:9791
>>>#14 0x4001fbaa in _svmh_invoke_nonvirtual_jlclass_initialize=20
>>>(env=3D0x804d548, this=3D0x8065b08, param_1=3D1) at method_invoke.c:35=
2
>>>#15 0x4003dcaa in _svmf_class_initialization (env=3D0x804d548,=20
>>>class=3D0x41450008)
>>>   at initialization.c:24
>>>#16 0x4008c6d5 in Java_java_lang_VirtualMachine_invokeMain=20
>>>(_env=3D0x804d548, _class=3D0x805fda8, mainClass=3D0x805fdb8, args=3D0=
x805fdc8)
>>>   at java_lang_VirtualMachine.c:47
>>>#17 0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
>>>#18 0x400df41a in ffi_call () from /usr/lib/libffi.so.2
>>>#19 0x40032bf8 in _svmf_invoke_native_static (env=3D0x804d548) at=20
>>>native.c:834
>>>#20 0x40071aa4 in _svmf_interpreter (_env=3D0x804d548)
>>>   at instructions_switch.c:9791
>>>#21 0x40057a60 in CallStaticVoidMethod (_env=3D0x804d548, cls=3D0x805f=
198,=20
>>>   methodID=3D0x41250818) at native_interface.c:14894
>>>#22 0x0804aa4d in main (argc=3D2, argv=3D0xbffff8e4) at sablevm.c:1434=

>>>(gdb)=20
>>>
>>>
>>>----------------------------------------------------------------------=
--
>>>
>>>
>>>public class Hello {
>>>
>>> static {
>>>   System.loadLibrary("hello");
>>> }
>>>
>>> private static native void printHello();
>>>
>>>
>>> public static void main(String[] args) {
>>>   printHello();
>>> }
>>>
>>>}
>>>
>>>
>>>----------------------------------------------------------------------=
--
>>>
>>>#include "Hello.h"
>>>
>>>#include <stdio.h>
>>>
>>>JNIEXPORT void JNICALL Java_Hello_printHello
>>>(JNIEnv *env, jclass c) {
>>> printf("Hello!\n");
>>>}
>>>
>>>
>>>
>>>----------------------------------------------------------------------=
--
>>>
>>>/* DO NOT EDIT THIS FILE - it is machine generated */
>>>#include <jni.h>
>>>/* Header for class Hello */
>>>
>>>#ifndef _Included_Hello
>>>#define _Included_Hello
>>>#ifdef __cplusplus
>>>extern "C" {
>>>#endif
>>>/*
>>>* Class:     Hello
>>>* Method:    printHello
>>>* Signature: ()V
>>>*/
>>>JNIEXPORT void JNICALL Java_Hello_printHello
>>> (JNIEnv *, jclass);
>>>
>>>#ifdef __cplusplus
>>>}
>>>#endif
>>>#endif
>>>
>>>
>>>----------------------------------------------------------------------=
--
>>>
>>>all:
>>>	libtool gcc -c -g -o hello.lo -I../../../../include Hello.c
>>>	libtool gcc -o libhello.la -g hello.lo -rpath `pwd`
>>>	libtool install -c libhello.la `pwd`/libhello.la
>>
>>--=20
>>Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
>>SableVM:                                       http://www.sablevm.org/
>>SableCC:                                       http://www.sablecc.org/
>=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] native libs

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

I was able to fix it.  I was confused for quite some time by a pointer
getting "magically" the value NULL.

From my understanding there is a bootstrap class loader and
"application" class loader(s).  The native library list in the applicatio=
n
class loader is initially NULL.  The code in
java_lang_Runtime_nativeLoad does not check if the list is initially
NULL.  The bootstrap class loader library happened not to be initially
null since is
it is initialized early with sablevm itself elsewhere.

I will clean up my code and send a patch via the bug tack system.


David

On Mon, Jan 20, 2003 at 04:21:01PM -0500, Prof. Etienne M. Gagnon wrote:
> OK.  I'm back!  :-)
>=20
> I'll look at this tomorrow.  You're on Debian/x86, right?
>=20
> Etienne
>=20
> David Paul BELANGER wrote:
> >Hi,
> >
> >I'm getting a segmentation fault when trying to load a native library.
> >The system native library (libjava-lang, libjava-io) get properly load=
ed
> >but when it comes to mine, it seems that the pointer passed to the
> >memory allocator is null.  My library seems to get properly loaded (th=
e
> >handle is non-null).
> >
> >I have included some gdb output and a simple Hello program that cause
> >the error.
> >
> >Thanks,
> >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
> >
> >
> >
> >----------------------------------------------------------------------=
--
> >
> >Program received signal SIGSEGV, Segmentation fault.
> >[Switching to Thread 1024 (LWP 10068)]
> >0x40029cbe in _svmf_cl_alloc (env=3D0x804d548, class_loader_info=3D0x8=
0636b8,=20
> >    size=3D12, ptr=3D0x0) at class_loader_memory_manager.c:139
> >139     class_loader_memory_manager.c: No such file or directory.
> >        in class_loader_memory_manager.c
> >(gdb) backtrace
> >#0  0x40029cbe in _svmf_cl_alloc (env=3D0x804d548,=20
> >class_loader_info=3D0x80636b8, size=3D12, ptr=3D0x0) at=20
> >    class_loader_memory_manager.c:139
> >#1  0x40029dd4 in _svmf_cl_zalloc (env=3D0x804d548,=20
> >class_loader_info=3D0x80636b8, size=3D12, ptr=3D0x0) at=20
> >    class_loader_memory_manager.c:181
> >#2  0x4002aab2 in _svmh_cl_zalloc_native_library (env=3D0x804d548,=20
> >    class_loader_info=3D0x80636b8, ptr=3D0x0) at cl_alloc.c:585
> >#3  0x400890ea in Java_java_lang_Runtime_nativeLoad (_env=3D0x804d548,=
=20
> >    this=3D0x8060028, _filename=3D0x8060610) at java_lang_Runtime.c:24=
6
> >#4  0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> >#5  0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> >#6  0x400334f8 in _svmf_invoke_native_nonstatic (env=3D0x804d548) at=20
> >native.c:1171
> >#7  0x40071b53 in _svmf_interpreter (_env=3D0x804d548)
> >    at instructions_switch.c:9839
> >#8  0x40027270 in _svmh_invoke_specific_static_clinit (env=3D0x804d548=
,=20
> >    method=3D0x4145046c) at method_invoke.c:5061
> >#9  0x40088c9e in Java_java_lang_Class_step8 (_env=3D0x804d548,=20
> >_class=3D0x805fd98, vmData=3D0x80607a0) at java_lang_Class.c:741
> >#10 0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> >#11 0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> >#12 0x40032bf8 in _svmf_invoke_native_static (env=3D0x804d548) at=20
> >native.c:834
> >#13 0x40071aa4 in _svmf_interpreter (_env=3D0x804d548)
> >    at instructions_switch.c:9791
> >#14 0x4001fbaa in _svmh_invoke_nonvirtual_jlclass_initialize=20
> >(env=3D0x804d548, this=3D0x8065b08, param_1=3D1) at method_invoke.c:35=
2
> >#15 0x4003dcaa in _svmf_class_initialization (env=3D0x804d548,=20
> >class=3D0x41450008)
> >    at initialization.c:24
> >#16 0x4008c6d5 in Java_java_lang_VirtualMachine_invokeMain=20
> >(_env=3D0x804d548, _class=3D0x805fda8, mainClass=3D0x805fdb8, args=3D0=
x805fdc8)
> >    at java_lang_VirtualMachine.c:47
> >#17 0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> >#18 0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> >#19 0x40032bf8 in _svmf_invoke_native_static (env=3D0x804d548) at=20
> >native.c:834
> >#20 0x40071aa4 in _svmf_interpreter (_env=3D0x804d548)
> >    at instructions_switch.c:9791
> >#21 0x40057a60 in CallStaticVoidMethod (_env=3D0x804d548, cls=3D0x805f=
198,=20
> >    methodID=3D0x41250818) at native_interface.c:14894
> >#22 0x0804aa4d in main (argc=3D2, argv=3D0xbffff8e4) at sablevm.c:1434
> >(gdb)=20
> >
> >
> >----------------------------------------------------------------------=
--
> >
> >
> >public class Hello {
> >
> >  static {
> >    System.loadLibrary("hello");
> >  }
> >
> >  private static native void printHello();
> >
> >
> >  public static void main(String[] args) {
> >    printHello();
> >  }
> >
> >}
> >
> >
> >----------------------------------------------------------------------=
--
> >
> >#include "Hello.h"
> >
> >#include <stdio.h>
> >
> >JNIEXPORT void JNICALL Java_Hello_printHello
> >(JNIEnv *env, jclass c) {
> >  printf("Hello!\n");
> >}
> >
> >
> >
> >----------------------------------------------------------------------=
--
> >
> >/* DO NOT EDIT THIS FILE - it is machine generated */
> >#include <jni.h>
> >/* Header for class Hello */
> >
> >#ifndef _Included_Hello
> >#define _Included_Hello
> >#ifdef __cplusplus
> >extern "C" {
> >#endif
> >/*
> > * Class:     Hello
> > * Method:    printHello
> > * Signature: ()V
> > */
> >JNIEXPORT void JNICALL Java_Hello_printHello
> >  (JNIEnv *, jclass);
> >
> >#ifdef __cplusplus
> >}
> >#endif
> >#endif
> >
> >
> >----------------------------------------------------------------------=
--
> >
> >all:
> >	libtool gcc -c -g -o hello.lo -I../../../../include Hello.c
> >	libtool gcc -o libhello.la -g hello.lo -rpath `pwd`
> >	libtool install -c libhello.la `pwd`/libhello.la
>=20
> --=20
> Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
> SableVM:                                       http://www.sablevm.org/
> SableCC:                                       http://www.sablecc.org/

--=20

---

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

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

[Sablevm-developer] bidirectional object speedup

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

Etienne-

It was interesting to read in the dissertation that the bidirectional
object layout didn't contribute as much speedup as one might expect.

I wonder about trying a slight modification to help this- changing
the way reference arrays are indexed so that they array elements
are stored in-order instead of backwards. This would require a
little extra computation, since the array length must be included
in every element access, but the theory is that most array elements
are read in-order and that memory is optimized for sequential access
(similar to filesystems) rather than reverse access.

I don't know enough specifics about whether this really makes sense
or not, but it might make for an interesting experiment.

Just a thought :-)

Cheers,
-Archie

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

Re: [Sablevm-developer] native libs

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

Just to let you know that I have the same problem with version 1.0.5 on
x86.

David

On Mon, Jan 20, 2003 at 04:49:30PM -0500, David Paul BELANGER wrote:
>=20
> I have the same problem on both Debian/PPC and Debian/x86.  However, th=
e
> x86 version is the older 1.0.1 version installed in the sable lab.  The=
 PPC version is based on 1.0.5 with my PPC patch.  I will try on 1.0.5 on=
 x86 tonight.
>=20
>=20
> David
>=20
> On Mon, Jan 20, 2003 at 04:21:01PM -0500, Prof. Etienne M. Gagnon wrote=
:
> > OK.  I'm back!  :-)
> >=20
> > I'll look at this tomorrow.  You're on Debian/x86, right?
> >=20
> > Etienne
> >=20
> > David Paul BELANGER wrote:
> > >Hi,
> > >
> > >I'm getting a segmentation fault when trying to load a native librar=
y.
> > >The system native library (libjava-lang, libjava-io) get properly lo=
aded
> > >but when it comes to mine, it seems that the pointer passed to the
> > >memory allocator is null.  My library seems to get properly loaded (=
the
> > >handle is non-null).
> > >
> > >I have included some gdb output and a simple Hello program that caus=
e
> > >the error.
> > >
> > >Thanks,
> > >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
> > >
> > >
> > >
> > >--------------------------------------------------------------------=
----
> > >
> > >Program received signal SIGSEGV, Segmentation fault.
> > >[Switching to Thread 1024 (LWP 10068)]
> > >0x40029cbe in _svmf_cl_alloc (env=3D0x804d548, class_loader_info=3D0=
x80636b8,=20
> > >    size=3D12, ptr=3D0x0) at class_loader_memory_manager.c:139
> > >139     class_loader_memory_manager.c: No such file or directory.
> > >        in class_loader_memory_manager.c
> > >(gdb) backtrace
> > >#0  0x40029cbe in _svmf_cl_alloc (env=3D0x804d548,=20
> > >class_loader_info=3D0x80636b8, size=3D12, ptr=3D0x0) at=20
> > >    class_loader_memory_manager.c:139
> > >#1  0x40029dd4 in _svmf_cl_zalloc (env=3D0x804d548,=20
> > >class_loader_info=3D0x80636b8, size=3D12, ptr=3D0x0) at=20
> > >    class_loader_memory_manager.c:181
> > >#2  0x4002aab2 in _svmh_cl_zalloc_native_library (env=3D0x804d548,=20
> > >    class_loader_info=3D0x80636b8, ptr=3D0x0) at cl_alloc.c:585
> > >#3  0x400890ea in Java_java_lang_Runtime_nativeLoad (_env=3D0x804d54=
8,=20
> > >    this=3D0x8060028, _filename=3D0x8060610) at java_lang_Runtime.c:=
246
> > >#4  0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> > >#5  0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> > >#6  0x400334f8 in _svmf_invoke_native_nonstatic (env=3D0x804d548) at=
=20
> > >native.c:1171
> > >#7  0x40071b53 in _svmf_interpreter (_env=3D0x804d548)
> > >    at instructions_switch.c:9839
> > >#8  0x40027270 in _svmh_invoke_specific_static_clinit (env=3D0x804d5=
48,=20
> > >    method=3D0x4145046c) at method_invoke.c:5061
> > >#9  0x40088c9e in Java_java_lang_Class_step8 (_env=3D0x804d548,=20
> > >_class=3D0x805fd98, vmData=3D0x80607a0) at java_lang_Class.c:741
> > >#10 0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> > >#11 0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> > >#12 0x40032bf8 in _svmf_invoke_native_static (env=3D0x804d548) at=20
> > >native.c:834
> > >#13 0x40071aa4 in _svmf_interpreter (_env=3D0x804d548)
> > >    at instructions_switch.c:9791
> > >#14 0x4001fbaa in _svmh_invoke_nonvirtual_jlclass_initialize=20
> > >(env=3D0x804d548, this=3D0x8065b08, param_1=3D1) at method_invoke.c:=
352
> > >#15 0x4003dcaa in _svmf_class_initialization (env=3D0x804d548,=20
> > >class=3D0x41450008)
> > >    at initialization.c:24
> > >#16 0x4008c6d5 in Java_java_lang_VirtualMachine_invokeMain=20
> > >(_env=3D0x804d548, _class=3D0x805fda8, mainClass=3D0x805fdb8, args=3D=
0x805fdc8)
> > >    at java_lang_VirtualMachine.c:47
> > >#17 0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> > >#18 0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> > >#19 0x40032bf8 in _svmf_invoke_native_static (env=3D0x804d548) at=20
> > >native.c:834
> > >#20 0x40071aa4 in _svmf_interpreter (_env=3D0x804d548)
> > >    at instructions_switch.c:9791
> > >#21 0x40057a60 in CallStaticVoidMethod (_env=3D0x804d548, cls=3D0x80=
5f198,=20
> > >    methodID=3D0x41250818) at native_interface.c:14894
> > >#22 0x0804aa4d in main (argc=3D2, argv=3D0xbffff8e4) at sablevm.c:14=
34
> > >(gdb)=20
> > >
> > >
> > >--------------------------------------------------------------------=
----
> > >
> > >
> > >public class Hello {
> > >
> > >  static {
> > >    System.loadLibrary("hello");
> > >  }
> > >
> > >  private static native void printHello();
> > >
> > >
> > >  public static void main(String[] args) {
> > >    printHello();
> > >  }
> > >
> > >}
> > >
> > >
> > >--------------------------------------------------------------------=
----
> > >
> > >#include "Hello.h"
> > >
> > >#include <stdio.h>
> > >
> > >JNIEXPORT void JNICALL Java_Hello_printHello
> > >(JNIEnv *env, jclass c) {
> > >  printf("Hello!\n");
> > >}
> > >
> > >
> > >
> > >--------------------------------------------------------------------=
----
> > >
> > >/* DO NOT EDIT THIS FILE - it is machine generated */
> > >#include <jni.h>
> > >/* Header for class Hello */
> > >
> > >#ifndef _Included_Hello
> > >#define _Included_Hello
> > >#ifdef __cplusplus
> > >extern "C" {
> > >#endif
> > >/*
> > > * Class:     Hello
> > > * Method:    printHello
> > > * Signature: ()V
> > > */
> > >JNIEXPORT void JNICALL Java_Hello_printHello
> > >  (JNIEnv *, jclass);
> > >
> > >#ifdef __cplusplus
> > >}
> > >#endif
> > >#endif
> > >
> > >
> > >--------------------------------------------------------------------=
----
> > >
> > >all:
> > >	libtool gcc -c -g -o hello.lo -I../../../../include Hello.c
> > >	libtool gcc -o libhello.la -g hello.lo -rpath `pwd`
> > >	libtool install -c libhello.la `pwd`/libhello.la
> >=20
> > --=20
> > Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon=
/
> > SableVM:                                       http://www.sablevm.org=
/
> > SableCC:                                       http://www.sablecc.org=
/
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> > are you planning your Web Server Security? Click here to get a FREE
> > Thawte SSL guide and find the answers to all your  SSL security issue=
s.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> > _______________________________________________
> > Sablevm-developer mailing list
> > Sab...@li...
> > https://lists.sourceforge.net/lists/listinfo/sablevm-developer
>=20
> --=20
>=20
> ---
>=20
> David B=E9langer
> Graduate Student
> School of Computer Science
> McGill University
> Office: MC226
>=20
> Web page:   http://www.cs.mcgill.ca/~dbelan2/
> Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

--=20

---

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

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

Re: [Sablevm-developer] native libs

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

I have the same problem on both Debian/PPC and Debian/x86.  However, the
x86 version is the older 1.0.1 version installed in the sable lab.  The P=
PC version is based on 1.0.5 with my PPC patch.  I will try on 1.0.5 on x=
86 tonight.


David

On Mon, Jan 20, 2003 at 04:21:01PM -0500, Prof. Etienne M. Gagnon wrote:
> OK.  I'm back!  :-)
>=20
> I'll look at this tomorrow.  You're on Debian/x86, right?
>=20
> Etienne
>=20
> David Paul BELANGER wrote:
> >Hi,
> >
> >I'm getting a segmentation fault when trying to load a native library.
> >The system native library (libjava-lang, libjava-io) get properly load=
ed
> >but when it comes to mine, it seems that the pointer passed to the
> >memory allocator is null.  My library seems to get properly loaded (th=
e
> >handle is non-null).
> >
> >I have included some gdb output and a simple Hello program that cause
> >the error.
> >
> >Thanks,
> >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
> >
> >
> >
> >----------------------------------------------------------------------=
--
> >
> >Program received signal SIGSEGV, Segmentation fault.
> >[Switching to Thread 1024 (LWP 10068)]
> >0x40029cbe in _svmf_cl_alloc (env=3D0x804d548, class_loader_info=3D0x8=
0636b8,=20
> >    size=3D12, ptr=3D0x0) at class_loader_memory_manager.c:139
> >139     class_loader_memory_manager.c: No such file or directory.
> >        in class_loader_memory_manager.c
> >(gdb) backtrace
> >#0  0x40029cbe in _svmf_cl_alloc (env=3D0x804d548,=20
> >class_loader_info=3D0x80636b8, size=3D12, ptr=3D0x0) at=20
> >    class_loader_memory_manager.c:139
> >#1  0x40029dd4 in _svmf_cl_zalloc (env=3D0x804d548,=20
> >class_loader_info=3D0x80636b8, size=3D12, ptr=3D0x0) at=20
> >    class_loader_memory_manager.c:181
> >#2  0x4002aab2 in _svmh_cl_zalloc_native_library (env=3D0x804d548,=20
> >    class_loader_info=3D0x80636b8, ptr=3D0x0) at cl_alloc.c:585
> >#3  0x400890ea in Java_java_lang_Runtime_nativeLoad (_env=3D0x804d548,=
=20
> >    this=3D0x8060028, _filename=3D0x8060610) at java_lang_Runtime.c:24=
6
> >#4  0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> >#5  0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> >#6  0x400334f8 in _svmf_invoke_native_nonstatic (env=3D0x804d548) at=20
> >native.c:1171
> >#7  0x40071b53 in _svmf_interpreter (_env=3D0x804d548)
> >    at instructions_switch.c:9839
> >#8  0x40027270 in _svmh_invoke_specific_static_clinit (env=3D0x804d548=
,=20
> >    method=3D0x4145046c) at method_invoke.c:5061
> >#9  0x40088c9e in Java_java_lang_Class_step8 (_env=3D0x804d548,=20
> >_class=3D0x805fd98, vmData=3D0x80607a0) at java_lang_Class.c:741
> >#10 0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> >#11 0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> >#12 0x40032bf8 in _svmf_invoke_native_static (env=3D0x804d548) at=20
> >native.c:834
> >#13 0x40071aa4 in _svmf_interpreter (_env=3D0x804d548)
> >    at instructions_switch.c:9791
> >#14 0x4001fbaa in _svmh_invoke_nonvirtual_jlclass_initialize=20
> >(env=3D0x804d548, this=3D0x8065b08, param_1=3D1) at method_invoke.c:35=
2
> >#15 0x4003dcaa in _svmf_class_initialization (env=3D0x804d548,=20
> >class=3D0x41450008)
> >    at initialization.c:24
> >#16 0x4008c6d5 in Java_java_lang_VirtualMachine_invokeMain=20
> >(_env=3D0x804d548, _class=3D0x805fda8, mainClass=3D0x805fdb8, args=3D0=
x805fdc8)
> >    at java_lang_VirtualMachine.c:47
> >#17 0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> >#18 0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> >#19 0x40032bf8 in _svmf_invoke_native_static (env=3D0x804d548) at=20
> >native.c:834
> >#20 0x40071aa4 in _svmf_interpreter (_env=3D0x804d548)
> >    at instructions_switch.c:9791
> >#21 0x40057a60 in CallStaticVoidMethod (_env=3D0x804d548, cls=3D0x805f=
198,=20
> >    methodID=3D0x41250818) at native_interface.c:14894
> >#22 0x0804aa4d in main (argc=3D2, argv=3D0xbffff8e4) at sablevm.c:1434
> >(gdb)=20
> >
> >
> >----------------------------------------------------------------------=
--
> >
> >
> >public class Hello {
> >
> >  static {
> >    System.loadLibrary("hello");
> >  }
> >
> >  private static native void printHello();
> >
> >
> >  public static void main(String[] args) {
> >    printHello();
> >  }
> >
> >}
> >
> >
> >----------------------------------------------------------------------=
--
> >
> >#include "Hello.h"
> >
> >#include <stdio.h>
> >
> >JNIEXPORT void JNICALL Java_Hello_printHello
> >(JNIEnv *env, jclass c) {
> >  printf("Hello!\n");
> >}
> >
> >
> >
> >----------------------------------------------------------------------=
--
> >
> >/* DO NOT EDIT THIS FILE - it is machine generated */
> >#include <jni.h>
> >/* Header for class Hello */
> >
> >#ifndef _Included_Hello
> >#define _Included_Hello
> >#ifdef __cplusplus
> >extern "C" {
> >#endif
> >/*
> > * Class:     Hello
> > * Method:    printHello
> > * Signature: ()V
> > */
> >JNIEXPORT void JNICALL Java_Hello_printHello
> >  (JNIEnv *, jclass);
> >
> >#ifdef __cplusplus
> >}
> >#endif
> >#endif
> >
> >
> >----------------------------------------------------------------------=
--
> >
> >all:
> >	libtool gcc -c -g -o hello.lo -I../../../../include Hello.c
> >	libtool gcc -o libhello.la -g hello.lo -rpath `pwd`
> >	libtool install -c libhello.la `pwd`/libhello.la
>=20
> --=20
> Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
> SableVM:                                       http://www.sablevm.org/
> SableCC:                                       http://www.sablecc.org/
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

--=20

---

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

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

Re: [Sablevm-developer] native libs

[Prof. E. M. G. <eti...@uq...>]

OK.  I'm back!  :-)

I'll look at this tomorrow.  You're on Debian/x86, right?

Etienne

David Paul BELANGER wrote:
> Hi,
>=20
> I'm getting a segmentation fault when trying to load a native library.
> The system native library (libjava-lang, libjava-io) get properly loade=
d
> but when it comes to mine, it seems that the pointer passed to the
> memory allocator is null.  My library seems to get properly loaded (the=

> handle is non-null).
>=20
> I have included some gdb output and a simple Hello program that cause
> the error.
>=20
> Thanks,
> David
>=20
>=20
> ---
>=20
> David B=E9langer
> Graduate Student
> School of Computer Science
> McGill University
> Office: MC226
>=20
> Web page:   http://www.cs.mcgill.ca/~dbelan2/
> Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 10068)]
> 0x40029cbe in _svmf_cl_alloc (env=3D0x804d548, class_loader_info=3D0x80=
636b8,=20
>     size=3D12, ptr=3D0x0) at class_loader_memory_manager.c:139
> 139     class_loader_memory_manager.c: No such file or directory.
>         in class_loader_memory_manager.c
> (gdb) backtrace
> #0  0x40029cbe in _svmf_cl_alloc (env=3D0x804d548, class_loader_info=3D=
0x80636b8,=20
>     size=3D12, ptr=3D0x0) at class_loader_memory_manager.c:139
> #1  0x40029dd4 in _svmf_cl_zalloc (env=3D0x804d548, class_loader_info=3D=
0x80636b8,=20
>     size=3D12, ptr=3D0x0) at class_loader_memory_manager.c:181
> #2  0x4002aab2 in _svmh_cl_zalloc_native_library (env=3D0x804d548,=20
>     class_loader_info=3D0x80636b8, ptr=3D0x0) at cl_alloc.c:585
> #3  0x400890ea in Java_java_lang_Runtime_nativeLoad (_env=3D0x804d548, =

>     this=3D0x8060028, _filename=3D0x8060610) at java_lang_Runtime.c:246=

> #4  0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> #5  0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> #6  0x400334f8 in _svmf_invoke_native_nonstatic (env=3D0x804d548) at na=
tive.c:1171
> #7  0x40071b53 in _svmf_interpreter (_env=3D0x804d548)
>     at instructions_switch.c:9839
> #8  0x40027270 in _svmh_invoke_specific_static_clinit (env=3D0x804d548,=
=20
>     method=3D0x4145046c) at method_invoke.c:5061
> #9  0x40088c9e in Java_java_lang_Class_step8 (_env=3D0x804d548, _class=3D=
0x805fd98,=20
>     vmData=3D0x80607a0) at java_lang_Class.c:741
> #10 0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> #11 0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> #12 0x40032bf8 in _svmf_invoke_native_static (env=3D0x804d548) at nativ=
e.c:834
> #13 0x40071aa4 in _svmf_interpreter (_env=3D0x804d548)
>     at instructions_switch.c:9791
> #14 0x4001fbaa in _svmh_invoke_nonvirtual_jlclass_initialize (env=3D0x8=
04d548,=20
>     this=3D0x8065b08, param_1=3D1) at method_invoke.c:352
> #15 0x4003dcaa in _svmf_class_initialization (env=3D0x804d548, class=3D=
0x41450008)
>     at initialization.c:24
> #16 0x4008c6d5 in Java_java_lang_VirtualMachine_invokeMain (_env=3D0x80=
4d548,=20
>     _class=3D0x805fda8, mainClass=3D0x805fdb8, args=3D0x805fdc8)
>     at java_lang_VirtualMachine.c:47
> #17 0x400df6ff in ffi_call_SYSV () from /usr/lib/libffi.so.2
> #18 0x400df41a in ffi_call () from /usr/lib/libffi.so.2
> #19 0x40032bf8 in _svmf_invoke_native_static (env=3D0x804d548) at nativ=
e.c:834
> #20 0x40071aa4 in _svmf_interpreter (_env=3D0x804d548)
>     at instructions_switch.c:9791
> #21 0x40057a60 in CallStaticVoidMethod (_env=3D0x804d548, cls=3D0x805f1=
98,=20
>     methodID=3D0x41250818) at native_interface.c:14894
> #22 0x0804aa4d in main (argc=3D2, argv=3D0xbffff8e4) at sablevm.c:1434
> (gdb)=20
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
>=20
> public class Hello {
>=20
>   static {
>     System.loadLibrary("hello");
>   }
>=20
>   private static native void printHello();
>=20
>=20
>   public static void main(String[] args) {
>     printHello();
>   }
>=20
> }
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> #include "Hello.h"
>=20
> #include <stdio.h>
>=20
> JNIEXPORT void JNICALL Java_Hello_printHello
> (JNIEnv *env, jclass c) {
>   printf("Hello!\n");
> }
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> /* DO NOT EDIT THIS FILE - it is machine generated */
> #include <jni.h>
> /* Header for class Hello */
>=20
> #ifndef _Included_Hello
> #define _Included_Hello
> #ifdef __cplusplus
> extern "C" {
> #endif
> /*
>  * Class:     Hello
>  * Method:    printHello
>  * Signature: ()V
>  */
> JNIEXPORT void JNICALL Java_Hello_printHello
>   (JNIEnv *, jclass);
>=20
> #ifdef __cplusplus
> }
> #endif
> #endif
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> all:
> 	libtool gcc -c -g -o hello.lo -I../../../../include Hello.c
> 	libtool gcc -o libhello.la -g hello.lo -rpath `pwd`
> 	libtool install -c libhello.la `pwd`/libhello.la

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

[Sablevm-developer] native libs

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

Hi,

I'm getting a segmentation fault when trying to load a native library.
The system native library (libjava-lang, libjava-io) get properly loaded
but when it comes to mine, it seems that the pointer passed to the
memory allocator is null.  My library seems to get properly loaded (the
handle is non-null).

I have included some gdb output and a simple Hello program that cause
the error.

Thanks,
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 & Jikes: java.lang.UnsupportedClassVersionError

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

W liście z sob, 18-01-2003, godz. 08:57, Ahmed pisze: 
> Hi,
> 
> $ cat Hello.java
> class Hello {
>     public static void main(String[] args) {
>         System.out.println("Hello.");
>     }
> }
> $ jikes-sable Hello.java
> $ sablevm --no-copyright Hello
> java.lang.UnsupportedClassVersionError
>         at java.lang.VMClassLoader.nativeDefineClass(VMClassLoader.java)
>         at java.lang.VMClassLoader.defineClass(VMClassLoader.java:78)
>         at java.lang.VMClassLoader.defineClass(VMClassLoader.java:121)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:587)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:555)
>         at 
> gnu.java.lang.SystemClassLoader.findClass(SystemClassLoader.java:108)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:259)
>         at java.lang.VirtualMachine.main(VirtualMachine.java:79)
> $
> 
> My versions:
> sablevm 1.0.5-1
> jikes-sable 1:1.18-1
> jikes 1:1.18-1
> 
> The only thing I found on the net is at:
> http://sourceforge.net/mailarchive/forum.php?thread_id=1437356&forum_id=4151.
> 
> Does Jikes 1.18 bytecode work with SableVM 1.0.5?
As far as I know - No, it doesn't.

Please use jikes from testing distro (1.15). You shouldn't have any
other problems because of that. Bytecode outputed by newer
jikes makes use of some functions that SableVM doesn't have yet.

It's good question to the upstream when it will get that functions.
But I am am sure it's the no. 1 on the TODO list as soon as the author
gets back from his vacations.

BTW: I tested above example w/ jikes 1.15 (and jikes-sable wrapper
from current jikes package version) and it worked.

					Grzegorz B. Prokopski
-- 
Grzegorz B. Prokopski <ga...@de...>
Debian http://www.debian.org/

[Sablevm-developer] Re: SableVm question on SpecJvm98

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

Hi Dayong,

I have attached the script I used to collect GC time measurements.  It is easy 
to modify to collect other measurements (and adjust parameters).

It assumes that you put each SPEC benchmark in a subdirectory called: 
SPEC_javac, SPEC_db, ...
and that you put SableCC and Soot in subdirectories called: SableCC and SOOT

In each of these directories, you should put a file called "entryPoint" which 
contains the name of the main class of the benchmark.

You should put the classes of each benchmark in a sub-subdirectory called 
"classes", and put any input file in the appropriate directory.

Here's the tree for the SPEC_compress benchmark (as shown by "find ."):

.
./SPEC_compress
./SPEC_compress/classes
./SPEC_compress/classes/spec
./SPEC_compress/classes/spec/benchmarks
./SPEC_compress/classes/spec/benchmarks/_201_compress
./SPEC_compress/classes/spec/benchmarks/_201_compress/Compress.java.v18a
./SPEC_compress/classes/spec/benchmarks/_201_compress/Code_Table.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Comp_Base.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Compress.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Compress.java
./SPEC_compress/classes/spec/benchmarks/_201_compress/Decompressor$Suffix_Table.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Compressor$Hash_Table.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Compressor.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Decompressor$De_Stack.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Decompressor.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Harness.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Harness.java
./SPEC_compress/classes/spec/benchmarks/_201_compress/Input_Buffer.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Main.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/Main.java
./SPEC_compress/classes/spec/benchmarks/_201_compress/Output_Buffer.class
./SPEC_compress/classes/spec/benchmarks/_201_compress/validity1.dat
./SPEC_compress/classes/spec/benchmarks/_201_compress/validity10.dat
./SPEC_compress/classes/spec/benchmarks/_201_compress/validity100.dat
./SPEC_compress/classes/spec/harness
./SPEC_compress/classes/spec/harness/BenchmarkDone.class
./SPEC_compress/classes/spec/harness/About.class
./SPEC_compress/classes/spec/harness/About.java
./SPEC_compress/classes/spec/harness/OrderedProperties.class
./SPEC_compress/classes/spec/harness/BenchmarkDone.java
./SPEC_compress/classes/spec/harness/BenchmarkTime.class
./SPEC_compress/classes/spec/harness/BenchmarkTime.java
./SPEC_compress/classes/spec/harness/Changes.v18
./SPEC_compress/classes/spec/harness/ConsoleWindow.class
./SPEC_compress/classes/spec/harness/ConsoleWindow.java
./SPEC_compress/classes/spec/harness/Constraints.class
./SPEC_compress/classes/spec/harness/Constraints.java
./SPEC_compress/classes/spec/harness/Context.class
./SPEC_compress/classes/spec/harness/Context.java
./SPEC_compress/classes/spec/harness/Dialog2.class
./SPEC_compress/classes/spec/harness/Dialog2.java
./SPEC_compress/classes/spec/harness/Dialog2Card.class
./SPEC_compress/classes/spec/harness/Dialog2Card.java
./SPEC_compress/classes/spec/harness/Logo.class
./SPEC_compress/classes/spec/harness/Logo.java
./SPEC_compress/classes/spec/harness/StopBenchmarkException.class
./SPEC_compress/classes/spec/harness/OrderedProperties.java
./SPEC_compress/classes/spec/harness/ProgramRunner.class
./SPEC_compress/classes/spec/harness/ProgramRunner.java
./SPEC_compress/classes/spec/harness/QuickCalc.class
./SPEC_compress/classes/spec/harness/QuickCalc.java
./SPEC_compress/classes/spec/harness/QuickSort.class
./SPEC_compress/classes/spec/harness/QuickSort.java
./SPEC_compress/classes/spec/harness/ReportFrame.class
./SPEC_compress/classes/spec/harness/ReportFrame.java
./SPEC_compress/classes/spec/harness/RunProgram.class
./SPEC_compress/classes/spec/harness/RunProgram.java
./SPEC_compress/classes/spec/harness/SpecBenchmark.class
./SPEC_compress/classes/spec/harness/SpecBenchmark.java
./SPEC_compress/classes/spec/harness/SpecJava.class
./SPEC_compress/classes/spec/harness/SpecJava.java
./SPEC_compress/classes/spec/harness/SpecProps.class
./SPEC_compress/classes/spec/harness/SpecProps.java
./SPEC_compress/classes/spec/harness/StopBenchmarkException.java
./SPEC_compress/classes/spec/harness/TestProperties.class
./SPEC_compress/classes/spec/harness/TuningNotes.class
./SPEC_compress/classes/spec/harness/TuningNotes.java
./SPEC_compress/classes/spec/io
./SPEC_compress/classes/spec/io/ValidityCheckOutputStream.class
./SPEC_compress/classes/spec/io/ConsoleOutputStream.class
./SPEC_compress/classes/spec/io/ConsoleOutputStream.java
./SPEC_compress/classes/spec/io/File.class
./SPEC_compress/classes/spec/io/File.java
./SPEC_compress/classes/spec/io/FileCacheData.class
./SPEC_compress/classes/spec/io/FileCacheData.java
./SPEC_compress/classes/spec/io/FileInputStream.class
./SPEC_compress/classes/spec/io/FileInputStream.java
./SPEC_compress/classes/spec/io/FileOutputStream.class
./SPEC_compress/classes/spec/io/FileOutputStream.java
./SPEC_compress/classes/spec/io/PrintStream.class
./SPEC_compress/classes/spec/io/PrintStream.java
./SPEC_compress/classes/spec/io/TableOfExistingFiles.class
./SPEC_compress/classes/spec/io/TableOfExistingFiles.java
./SPEC_compress/classes/spec/io/ValidityCheckOutputStream.java
./SPEC_compress/input
./SPEC_compress/input/202.tar
./SPEC_compress/input/205.tar
./SPEC_compress/input/208.tar
./SPEC_compress/input/209.tar
./SPEC_compress/input/210.tar
./SPEC_compress/input/211.tar
./SPEC_compress/input/213x.tar
./SPEC_compress/input/228.tar
./SPEC_compress/input/239.tar
./SPEC_compress/input/misc.tar
./SPEC_compress/times
./SPEC_compress/times/times.sablevm
./SPEC_compress/output
./SPEC_compress/output/stdout.log.sablevm
./SPEC_compress/entryPoint

The content of ./SPEC_compress/entryPoint is:
spec.benchmarks._201_compress.Main


I hope this helps

Etienne
PS: I have CCed the SableVM-devel list, as this message might be of interest to 
others.

gu dayong on CS McGill wrote:
> Hi, Prof. Gagnon:
> I am a student in McGill, my superviser is prof. Driesen.
> I am currently using SableVm.
> 
> I have use build-many to create different versions.
> The installation seems okay and the SableVm can execute
> some small java program correct.
> 
> But when I try to run the SpecJVM98 benchmarks, some problems
> occur:
> For example:
> When I run:
> sablevm SpecApplication _209_db
> 
> I get:
> 
> *** Couldn't bind native method Java_java_lang_Runtime_totalMemory ***
> *** or Java_java_lang_Runtime_totalMemory__ ***
> 
>>>>>spec.benchmarks._209_db.Main exited with exception:
> 
> java.lang.UnsatisfiedLinkError <<<<
> java.lang.UnsatisfiedLinkError
>         at java.lang.Runtime.totalMemory(Runtime.java)
>         at
> spec.harness.ProgramRunner.runBenchmark2(ProgramRunner.java:299)
> at spec.harness.ProgramRunner.runBenchmark(ProgramRunner.java:238)
>         at spec.harness.ProgramRunner.run(ProgramRunner.java:206)
>         at spec.harness.RunProgram.run(RunProgram.java:60)
>         at SpecApplication.runBenchmark(SpecApplication.java:255)
>         at SpecApplication.main(SpecApplication.java:171)
>         at java.lang.VirtualMachine.invokeMain(VirtualMachine.java)
>         at java.lang.VirtualMachine.main(VirtualMachine.java:88)
> 
> java.lang.NullPointerException
>         at SpecApplicationRunner.benchmarkDone(SpecApplication.java:281)
> 
>         at
> spec.harness.ProgramRunner.runBenchmark(ProgramRunner.java:244)
>         at spec.harness.ProgramRunner.run(ProgramRunner.java:206)
>         at spec.harness.RunProgram.run(RunProgram.java:60)
>         at SpecApplication.runBenchmark(SpecApplication.java:255)
>         at SpecApplication.main(SpecApplication.java:171)
>         at java.lang.VirtualMachine.invokeMain(VirtualMachine.java)
>         at java.lang.VirtualMachine.main(VirtualMachine.java:88)
> 
> The same thing happen to other SpecJVM98 benchmarks.
> 
> I can run the benchmarks by Jikes RVM and Sun Java. So it seems
> my SableVm has some problems.
> 
> Have you meet such a thing before? Could u give me some suggestion
> on it?
> 
> My System is Linux Mandrake 8.0  on Pentium III.
> 
>>From you Ph.D thesis, I know you have tested sablevm on these
> benchmarks.
> And you said you " not follow the official run rules" and
> "use "custom wrapper script". Is this script available now?
> 
> Could u teach me how to test the benchmarks on SableVm correctly?
> 
> 
> 
> Thank you!
> 
> Cheers,
> Dayong
> 

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

Re: [Sablevm-developer] Threads free list

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

Archie Cobbs wrote:
> It appears that the free list for threads is not actually used.
> I.e., when a thread exits, it is never put on the VM threads free list.
> The file thread.c contains this comment:
> 
> 	/* leak it for now... */
> 
> Is there some bug or problem exposed when threads are put back on
> the free list? It seems like it would be simple enough to implement
> this, and I'm wondering if there's a more subtle problem that I'm
> missing.

I just realized that you can't free the _svmt_JNIEnv object until
the corresponding java.lang.Thread object is GC'd. So it seems that
java.lang.Thread needs a finalize() method that does this... ?

-Archie

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

[Sablevm-developer] Threads free list

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

Hi,

It appears that the free list for threads is not actually used.
I.e., when a thread exits, it is never put on the VM threads free list.
The file thread.c contains this comment:

	/* leak it for now... */

Is there some bug or problem exposed when threads are put back on
the free list? It seems like it would be simple enough to implement
this, and I'm wondering if there's a more subtle problem that I'm
missing.

Thanks,
-Archie

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

[Sablevm-developer] _svmt_interned_string

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

It doesn't appear that the '_svmt_interned_string' type is used anywhere.
Can it be removed?

-Archie

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

[Sablevm-developer] 'current_class_file' field

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

Hi,

It seems like the 'current_class_file' field of the 'struct
_svmt_bootstrap_classloader_struct' structure is unnecessary,
as it's only used in _svmf_bootcl_derive_class(), and there's
no way that this function can be called recursively with
'current_class_file' non-empty, so it could be replaced with
a local variable in that function.

Is this analysis correct?

FYI, this is a minor point but I figured while reading through
the code I'd post any such questions FWIW...

Thanks,
-Archie

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

Re: [Sablevm-developer] Java_java_lang_Runtime_totalMemory: Link Error

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

On Tue, Jan 07, 2003 at 03:14:27PM -0700, Gunda Domlur wrote:
> Hello,
> 
> When I tried running a benchmark on sablevm-direct I got the following 
> error.
> 
> *** Couldn't find native method Java_java_lang_runtime_totalMemory ***
> *** or Java_java_lang_Runtime_totalMemory__ ***
> >>>>benchmarkmain exited with exception: java.lang.UnsatisfiedLinkError <<<<
> java.lang.UnsatisfiedLinkError
> 
> I tried looking in the native-library. There is a declaration for this 
> function in the java_lang_Runtime.h file, but no definition. Is this just 
> missing or should look for the definition elsewhere ?

It is currently missing.  It should be fairly easy to implement,
though.  Just look at the data structure _svmt_JavaVM->heap.

Etienne

> 
> Thanks.
> -Gunda
> 
> 
> 
> 
> 
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online 
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

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

[Sablevm-developer] Java_java_lang_Runtime_totalMemory: Link Error

[Gunda D. <sab...@ho...>]

Hello,

When I tried running a benchmark on sablevm-direct I got the following 
error.

*** Couldn't find native method Java_java_lang_runtime_totalMemory ***
*** or Java_java_lang_Runtime_totalMemory__ ***
>>>>benchmarkmain exited with exception: java.lang.UnsatisfiedLinkError <<<<
java.lang.UnsatisfiedLinkError

I tried looking in the native-library. There is a declaration for this 
function in the java_lang_Runtime.h file, but no definition. Is this just 
missing or should look for the definition elsewhere ?

Thanks.
-Gunda





_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: [Sablevm-developer] Re: [Sablevm-bugs] [ sablevm-Bugs-663270 ] [jni: fatal error (Local reference capacity exceeded)]

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

Etienne M. Gagnon wrote:
> This seems to be a local reference leak in Classpath...  The JNI
> specification says that a VM automatically reserves at least 16 local
> references.  To use additional references, the EnsureLocalCapacity()
> JNI function is available and shoould be called.
> 
> See:
> http://java.sun.com/products/jdk/1.2/docs/guide/jni/jni-12.html#EnsureLocalCapacity
> 
> A VM is *NOT* required to provide any more than 16 native references,
> by default, and can halt abruptly by calling FatalError() if it cannot
> create more locals. [OK, there's a note about backward compatibility,
> but my understanding is that this is for the JDK, not for every
> possible VM].
> 
> SableVM is simply strict in its implementation of the JNI spec (which
> simplifies local reference management a little).

Ah, I didn't realize that there was a limit... the last time I read
that spec was a few years ago before there was one! :-)

This is something very basic though. It turns out that it only
depends on the number of command line arguments, you don't even
have to execute any application Java. For example:

    $ sablevm asdf sadf asdf sad sadf sadf adsf sdf asdf asdf asdf asfd asdf
    [jni: fatal error (Local reference capacity exceeded)]

This is probably something to do with the way "sablevm" uses the
invocation interface to start things up.

As it stands, you can't give sablevm more than 12 command line
arguments (including the main() class name).

Cheers,
-Archie

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

[Sablevm-developer] Re: [Sablevm-bugs] [ sablevm-Bugs-663270 ] [jni: fatal error (Local reference capacity exceeded)]

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

First of all, I wish a happy new year 2003 to everyone.

This seems to be a local reference leak in Classpath...  The JNI
specification says that a VM automatically reserves at least 16 local
references.  To use additional references, the EnsureLocalCapacity()
JNI function is available and shoould be called.

See:
http://java.sun.com/products/jdk/1.2/docs/guide/jni/jni-12.html#EnsureLocalCapacity

A VM is *NOT* required to provide any more than 16 native references,
by default, and can halt abruptly by calling FatalError() if it cannot
create more locals. [OK, there's a note about backward compatibility,
but my understanding is that this is for the JDK, not for every
possible VM].

SableVM is simply strict in its implementation of the JNI spec (which
simplifies local reference management a little).

In fact, by aborting as it does, SableVM is helping to detect
weaknesses in the Classpath native library.

I personally think that this sould be filed as a bug against
Classpath, instead.

But, maybe I'll add a configure option to enable growing the local ref
frame automatically.  It shouldn't take more than 10 lines of code and
would make Archie happy;-)

Etienne

On Mon, Jan 06, 2003 at 11:16:53AM -0800, SourceForge.net wrote:
> Bugs item #663270, was opened at 2003-01-06 11:16
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523
> 
> Category: Execution Problem
> Group: SableVM
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Archie Cobbs (archiecobbs)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: [jni: fatal error (Local reference capacity exceeded)]
> 
> Initial Comment:
> I'm trying to run an application that uses Soot. If I
> try to process
> too many classfiles at once, I get this error plus a
> core dump:
> 
>   [jni: fatal error (Local reference capacity exceeded)]
> 
> This makes SableVM suddenly look like a "toy" Java VM when
> we know it's really better than that :-)
> 
> SableVM should handle this situation more gracefully,
> even if
> it means an 'escape' mechanism that's slower than normal or
> whatever.
> 
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Sablevm-bugs mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-bugs

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

[Sablevm-developer] sablevm now running on Mac OS X!

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

Hello,

This is just to announce that I was able to successfully run the HelloWor=
ld
program on Mac OS X / PPC.  It took me several days.

When I will have time, I will cleanup the code, do more tests and send
a patch.

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] Porting SableVM to ARM: Questions

[Gunda D. <sab...@ho...>]

Archie,

You are right. Dang, don't know how I missed that ! So the test for 
inlineability is more constrained for ARM. I will look at the m4 file again.

Later,
-Gunda


>From: Archie Cobbs <ar...@de...>
>To: Gunda Domlur <sab...@ho...>
>CC: eg...@j-..., ma...@kl..., 
>sab...@li...
>Subject: Re: [Sablevm-developer] Porting SableVM to ARM: Questions
>Date: Fri, 3 Jan 2003 09:33:52 -0800 (PST)
>
>Gunda Domlur wrote:
> > Now I am back after the holidays to look at the problem of making the
> > inlined version working on ARM.
>
>I happen to have been working with ARM assembly lately, on an
>unrelated project. One thing that may present difficulties for
>SableVM inline threading is the way that immediate values are
>handled.
>
>The ARM instruction set does not allow loading of arbitrary
>immediate values; to typically such values are stored in a
>'literals' pool at the end of whatever function, etc. you are
>assembling or compiling, and then they are loaded using a
>PC-relative instruction.
>
>This means that if you move the code, but don't move the
>literals, it won't work. Moreover, it's hard to predict when
>the compiler is going to do this, because some constants
>can be loaded as immediate values (specifically, those that
>can be represented as an 8-bit value shifted an even number
>of bits, or the ones complement of such a value).
>
>Here's an example. Consider this C code:
>
>	extern int x;
>	extern int y;
>	void
>	foo()
>	{
>		x = 0xff000000;	/* can be loaded as immediate */
>		y = 0x12345678;	/* cannot be loaded as immediate */
>	}
>
>Here's what GCC outputs:
>
>		.file   "foo.c"
>		.text
>		.align  2
>		.global foo
>		.type   foo,function
>	foo:
>		@ args = 0, pretend = 0, frame = 0
>		@ frame_needed = 0, uses_anonymous_args = 0
>		@ link register save eliminated.
>		ldr     r3, .L2
>		mov     r2, #-16777216
>		ldr     r1, .L2+4
>		str     r2, [r3, #0]
>		ldr     r3, .L2+8
>		@ lr needed for prologue
>		str     r1, [r3, #0]
>		bx      lr
>	.L3:
>		.align  2
>	.L2:
>		.word   x
>		.word   305419896
>		.word   y
>	.Lfe1:
>		.size   foo,.Lfe1-foo
>		.ident  "GCC: (GNU) 3.2"
>
>
>Note that the 0x12345678 (305419896) constant is stored in the literal
>pool (starting at .L2) but the 0xff000000 (-16777216) constant is not.
>The latter is 'relocatable' but the former is not.
>
>So this is going to be tricky to predict which instructions are
>inlinable; it also depends on how the compiler compiles code.
>
>-Archie
>
>__________________________________________________________________________
>Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com


_________________________________________________________________
Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

Re: [Sablevm-developer] Porting SableVM to ARM: Questions

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

Gunda Domlur wrote:
> Now I am back after the holidays to look at the problem of making the 
> inlined version working on ARM.

I happen to have been working with ARM assembly lately, on an
unrelated project. One thing that may present difficulties for
SableVM inline threading is the way that immediate values are
handled.

The ARM instruction set does not allow loading of arbitrary
immediate values; to typically such values are stored in a
'literals' pool at the end of whatever function, etc. you are
assembling or compiling, and then they are loaded using a
PC-relative instruction.

This means that if you move the code, but don't move the
literals, it won't work. Moreover, it's hard to predict when
the compiler is going to do this, because some constants
can be loaded as immediate values (specifically, those that
can be represented as an 8-bit value shifted an even number
of bits, or the ones complement of such a value).

Here's an example. Consider this C code:

	extern int x;
	extern int y;
	void
	foo()
	{
		x = 0xff000000;	/* can be loaded as immediate */
		y = 0x12345678;	/* cannot be loaded as immediate */
	}

Here's what GCC outputs:

		.file   "foo.c"
		.text
		.align  2
		.global foo
		.type   foo,function
	foo:
		@ args = 0, pretend = 0, frame = 0
		@ frame_needed = 0, uses_anonymous_args = 0
		@ link register save eliminated.
		ldr     r3, .L2
		mov     r2, #-16777216
		ldr     r1, .L2+4
		str     r2, [r3, #0]
		ldr     r3, .L2+8
		@ lr needed for prologue
		str     r1, [r3, #0]
		bx      lr
	.L3:
		.align  2
	.L2:
		.word   x
		.word   305419896
		.word   y
	.Lfe1:
		.size   foo,.Lfe1-foo
		.ident  "GCC: (GNU) 3.2"


Note that the 0x12345678 (305419896) constant is stored in the literal
pool (starting at .L2) but the 0xff000000 (-16777216) constant is not.
The latter is 'relocatable' but the former is not.

So this is going to be tricky to predict which instructions are
inlinable; it also depends on how the compiler compiles code.

-Archie

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

Re: [Sablevm-developer] Porting SableVM to ARM: Questions

[Gunda D. <sab...@ho...>]

Hi Etienne,

Now I am back after the holidays to look at the problem of making the 
inlined version working on ARM.

As per your previous suggestion (in a different discussion thread) I used 
the invocation

sablevm-inlined -v -p sablevm.verbose.methods=true -p 
sablevm.verbose.instructions=true HelloWorldApp

The program fails at different points in different runs. More than half the 
time GOTO is the last instruction executed. But the funny thing is that 
several GOTO's were executed before. Sometimes is fails on IFGT.

Any suggestions ?

Has anybody got sablevm-inlined working on other architectures (other than 
x86) ? I would love to hear their experiences.

Thanks.
-Gunda


>From: "Etienne M. Gagnon" <eg...@j-...>
>To: Gunda Domlur <sab...@ho...>
>CC: ma...@kl..., sab...@li...
>Subject: Re: [Sablevm-developer] Porting SableVM to ARM: Questions
>Date: Mon, 9 Dec 2002 21:35:59 -0500
>
>On Mon, Dec 09, 2002 at 04:54:50PM -0700, Gunda Domlur wrote:
> > The inlined version still fails. Why ? Any particular area I should look 
>at
> > to solve this problem ? I believe I have the _iflush routine implemented
> > correctly. Any pointers will be appreciated.
>
>Getting the inline-threaded engine to work is tricky.  I suggest that
>you live with the switch and threaded engines for a little time.  I'll
>be improving the portability framework for the inline-threaded engine
>in January 2003.  I'll add the following features:
>
>1- *partly* automatic detection of inlinability of instructions (on a
>specific architecture/compiler-options.
>
>2- Better separation of inlinability specifications for specific
>platform/compiler-options.
>
>
>Of course, you can read chapter 2 of my thesis, when I put it online,
>to get a better idea of the problem.  I just don't have time just now
>to explain all the details.
>
>Etienne
>
>--
>Etienne M. Gagnon                                    eg...@j-...
>SableVM:                                       http://www.sablevm.org/
>SableCC:                                       http://www.sablecc.org/
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Sablevm-developer mailing list
>Sab...@li...
>https://lists.sourceforge.net/lists/listinfo/sablevm-developer


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail