jamvm-general — General discussion of the Jam Virtual Machine.

Re: [Jamvm-general] QT-Jambi sigsegv at startup issue.

[Xerxes R. <xe...@za...>]

Updated testcase to use the last stable qt-jambi 4.6 community supported version, the 4.7 beta version consumed a lot of memory and can freeze the desktop on some Linux setups.

2012-06-15 12:10, Xerxes Rånby skrev:
> Hi
> I am testing JamVM git head + OpenJDK 6 1.11.1 against the qt-jambi framework on a 32bit x86 machine:
> 
> http://qt-jambi.org/ - Qt Jambi 4.7 beta this is the current actively maintained community supported version.
http://qt-jambi.org/downloads - Qt Jambi 4.6 stable download page.
> http://qt-project.org/wiki/Qt_Jambi - Qt Jambi 4.5.2_01. This is last version by the Qt team.

Testcase:
wget http://downloads.sourceforge.net/project/qtjambi/4.6.3/qtjambi-linux32-community-4.6.3.tar.gz
tar zxvf qtjambi-linux32-community-4.6.3.tar.gz
cd qtjambi-linux32-community-4.6.3
./qtjambi.sh

> the ./qtjambi.sh launches:
/usr/bin/java -cp ./qtjambi-util-4.6.3.jar:./qtjambi-linux32-gcc-4.6.3.jar:./qtjambi-examples-4.6.3.jar:./qtjambi-designer-4.6.3.jar:./qtjambi-4.6.3.jar: com.trolltech.launcher.Launcher

> 
> I get an immediate crash during qt-jambi startup while using jamvm in contrast both cacao and hotspot work to launch these qt-jambi examples.
> I hit the same issue for both the 4.7 and 4.5.2 version.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x003543d7 in executeJava () at interp.c:2182
> 2182	    DEF_OPC_210(OPC_INVOKEVIRTUAL_QUICK, {
> (gdb) bt
> #0  0x003543d7 in executeJava () at interp.c:2182
> #1  0x0033ba70 in executeMethodVaList (ob=0x0, class=0x993d3c50,
>     mb=0x94334254, jargs=0xb7fdc300 "") at execute.c:129
> #2  0x0033d3e6 in Jam_CallStaticVoidMethod (env=0x377900, clazz=0x993d3c50,
>     methodID=0x94334254) at jni.c:1221
> #3  0x0804baa9 in JavaMain ()
> #4  0x00138d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
> #5  0x00242ace in clone () from /lib/i386-linux-gnu/libc.so.6
> 
> Cheers
> Xerxes

[Jamvm-general] QT-Jambi sigsegv at startup issue.

[Xerxes R. <xe...@za...>]

Hi
I am testing JamVM git head + OpenJDK 6 1.11.1 against the qt-jambi framework on a 32bit x86 machine:

http://qt-jambi.org/ - Qt Jambi 4.7 beta this is the current actively maintained community supported version.
http://qt-project.org/wiki/Qt_Jambi - Qt Jambi 4.5.2_01. This is last version by the Qt team.

Testcase:
wget http://downloads.sourceforge.net/project/qtjambi/4.7.0-beta2/qtjambi-linux32-community-4.7.0-beta2.tar.gz
tar zxvf qtjambi-linux32-community-4.7.0-beta2.tar.gz
cd qtjambi-linux32-community-4.7.0-beta2
./qtjambi.sh

the ./qtjambi.sh launches:
/usr/bin/java -jamvm -cp ./qtjambi-util-4.7.0.jar:./qtjambi-linux32-gcc-4.7.0.jar:./qtjambi-examples-4.7.0.jar:./qtjambi-designer-4.7.0.jar:./qtjambi-4.7.0.jar: com.trolltech.launcher.Launcher

I get an immediate crash during qt-jambi startup while using jamvm in contrast both cacao and hotspot work to launch these qt-jambi examples.
I hit the same issue for both the 4.7 and 4.5.2 version.

Program received signal SIGSEGV, Segmentation fault.
0x003543d7 in executeJava () at interp.c:2182
2182	    DEF_OPC_210(OPC_INVOKEVIRTUAL_QUICK, {
(gdb) bt
#0  0x003543d7 in executeJava () at interp.c:2182
#1  0x0033ba70 in executeMethodVaList (ob=0x0, class=0x993d3c50,
    mb=0x94334254, jargs=0xb7fdc300 "") at execute.c:129
#2  0x0033d3e6 in Jam_CallStaticVoidMethod (env=0x377900, clazz=0x993d3c50,
    methodID=0x94334254) at jni.c:1221
#3  0x0804baa9 in JavaMain ()
#4  0x00138d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#5  0x00242ace in clone () from /lib/i386-linux-gnu/libc.so.6

Cheers
Xerxes

[Jamvm-general] query regarding malloc use with multi-thread in linux

[Deepak J. <dee...@el...>]

Hello JAMVM team,

I was curious about an issue I found in JAMVM 1.5.3 A deadlock,
what happened is when JAMVM cloned many threads(40),
and a few threads called malloc simultaneously, they entered a futex lock.

Now, what happened is the garbage collector thread called suspendAllthread,
and as one of the threads was stuck in futex lock,
it went in an infinite loop of sched_yield().

This is a generic problem in glibc,
but my question is that,
is there a way other JAMVM users have tried to solve it.
Like using mtmalloc, etc.
If yes, why not we include a thread safe version with JAMVM, itself.

I am not registered to the mailing list, so please do keep me in reply.

Best Regards,
Deepak Jangid

[Jamvm-general] ExceptionInInitializerError with jamvm

[Juser <bha...@gm...>]

Hi,

I have been doing some experiments with JAMVM on Mips OCTEON Processor. 
Jamvm works perfectly fine when using O32ABI. But compiling Jamvm for N32ABI
(Optimized compiler from Cavium) isn't working and errors as below. 
GNU Classpath 0.98 version is being used here.

(i) Encountered segmentation fault in the first case and one of the post in
jamvm mailing list
 suggested to use libffi to getaway with the issue.

(ii) Tried enabling ffi and now jamvm loads and using verbose can see
classes loading properly
 but eventually resulted in below errors.

> jamvm CaffeineMarkEmbeddedApp
#######################################
Exception in thread "main" java.lang.ExceptionInInitializerError
   at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:799)
Caused by: java.lang.NullPointerException
   at java.io.File.normalizePath(File.java:301)
   at java.io.File.<init>(File.java:282)
   at java.io.File.getCanonicalFile(File.java:527)
   at java.net.URLClassLoader.addURLImpl(URLClassLoader.java:307)
   at java.net.URLClassLoader.addURLs(URLClassLoader.java:418)
   at java.net.URLClassLoader.<init>(URLClassLoader.java:217)
   at java.lang.ClassLoader$1.<init>(ClassLoader.java:1099)
   at java.lang.ClassLoader.createSystemClassLoader(ClassLoader.java:1099)
   at
java.lang.ClassLoader.defaultGetSystemClassLoader(ClassLoader.java:1084)
   at java.lang.VMClassLoader.getSystemClassLoader(VMClassLoader.java:296)
   at java.lang.ClassLoader$StaticData.<clinit>(ClassLoader.java:154)
   at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:799)


With verbose 
> jamvm -verbose:jni CaffeineMarkEmbeddedApp
############################################
[Dynamic-linking native method java.lang.VMThrowable.fillInStackTrace ...
internal]
[Dynamic-linking native method gnu.classpath.VMSystemProperties.preInit ...
internal]
[Dynamic-linking native method java.lang.VMSystem.arraycopy ... internal]
[Dynamic-linking native method gnu.classpath.VMSystemProperties.postInit ...
internal]
[Dynamic-linking native method java.lang.VMObject.clone ... internal]
[Dynamic-linking native method
gnu.classpath.VMStackWalker.getCallingClassLoader ... internal]
[Dynamic-linking native method java.lang.VMRuntime.mapLibraryName ...
internal]
[Dynamic-linking native method java.lang.VMRuntime.nativeLoad ... internal]
[Opened native library /usr/local/classpath/lib/classpath/libjavanio.so]
[Dynamic-linking native method gnu.java.nio.VMChannel.initIDs ... JNI]
[Dynamic-linking native method gnu.java.nio.VMChannel.stdin_fd ... JNI]
[Dynamic-linking native method java.lang.VMClassLoader.getPrimitiveClass ...
internal]
[Dynamic-linking native method gnu.java.nio.VMChannel.stdout_fd ... JNI]
[Dynamic-linking native method gnu.java.nio.VMChannel.stderr_fd ... JNI]
[Opened native library /usr/local/classpath/lib/classpath/libjavaio.so]
[Dynamic-linking native method java.io.VMFile.isDirectory ... JNI]
[Opened native library /usr/local/classpath/lib/classpath/libjavalang.so]
[Dynamic-linking native method java.lang.VMString.intern ... internal]
[Dynamic-linking native method java.lang.VMObject.getClass ... internal]
[Dynamic-linking native method java.lang.VMSystem.identityHashCode ...
internal]
[Dynamic-linking native method java.lang.VMThread.currentThread ...
internal]
[Dynamic-linking native method java.lang.VMClass.forName ... internal]
[Dynamic-linking native method java.lang.VMClass.getDeclaredConstructors ...
internal]
[Dynamic-linking native method
java.lang.reflect.VMConstructor.getModifiersInternal ... internal]
[Dynamic-linking native method java.lang.VMClass.getModifiers ... internal]
[Dynamic-linking native method java.lang.reflect.VMConstructor.construct ...
internal]
[Dynamic-linking native method java.io.VMFile.toCanonicalForm ... JNI]
[Dynamic-linking native method gnu.java.nio.VMChannel.write ... JNI]
Exception in thread "main" [Dynamic-linking native method
java.lang.VMThrowable.getStackTrace ... internal]
[Dynamic-linking native method java.lang.VMClass.getName ... internal]
java.lang.ExceptionInInitializerError
   at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:799)
Caused by: java.lang.NullPointerException
   at java.io.File.normalizePath(File.java:301)
   at java.io.File.<init>(File.java:282)
   at java.io.File.getCanonicalFile(File.java:527)
   at java.net.URLClassLoader.addURLImpl(URLClassLoader.java:307)
   at java.net.URLClassLoader.addURLs(URLClassLoader.java:418)
   at java.net.URLClassLoader.<init>(URLClassLoader.java:217)
   at java.lang.ClassLoader$1.<init>(ClassLoader.java:1099)
   at java.lang.ClassLoader.createSystemClassLoader(ClassLoader.java:1099)
   at
java.lang.ClassLoader.defaultGetSystemClassLoader(ClassLoader.java:1084)
   at java.lang.VMClassLoader.getSystemClassLoader(VMClassLoader.java:296)
   at java.lang.ClassLoader$StaticData.<clinit>(ClassLoader.java:154)
   at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:799)
[Dynamic-linking native method java.lang.VMRuntime.exit ... internal]

Both jamvm, classpath are installed in /usr/local directory.

Appreciate your help in this regard.

Thanks,
Bhanu Prakash.
-- 
View this message in context: http://old.nabble.com/ExceptionInInitializerError-with-jamvm-tp33507418p33507418.html
Sent from the JamVM mailing list archive at Nabble.com.

Re: [Jamvm-general] Can JamVM optimize away static branches?

[Robert L. <rob...@gm...>]

On 23 February 2012 15:12, Xerxes Rånby <xe...@za...> wrote:
> I have attached a slightly more interesting testcase.
> This time the logic gets passed to JamVM.
>
> Can JamVM optimize away these static branches when the public static final are set at runtime?
>

Short answer, no.  Long answer, JamVMs JIT is pretty simplistic.  It
converts bytecode to native machine code but it doesn't really do any
optimising of the bytecode.  It's been my intention for several years
to add some easy optimisations at the bytecode level, but other things
always gets in the way.  Optimisation of runtime initialised finals
would also be pretty low on the list, as there's much more lower
hanging fruit.

Thanks,
Rob.

> Cheers
> Xerxes
>
> xranby@xranby-ESPRIMO-P7935:~$ cat foo.java
> public class foo {
>    public static boolean isDebug(){
>                String value = System.getProperty("debug");
>                if(value!=null)
>                        return true;
>                return false;
>    }
>
>    public static final boolean DEBUG=isDebug();
>
>    public static void main(String[] args) {
>        foo f = new foo();
>
>        if (f.DEBUG) {
>             System.out.print("I have a message to the user, ");
>        }
>
>        System.out.print("hello");
>
>        if (f.DEBUG) {
>             System.out.print(", i love you all,");
>        }
>
>        System.out.println(" world");
>    }
> }
>
>
> xranby@xranby-ESPRIMO-P7935:~$ java foo
> hello world
> xranby@xranby-ESPRIMO-P7935:~$ java -Ddebug foo
> I have a message to the user, hello, i love you all, world
>
> xranby@xranby-ESPRIMO-P7935:~$ javap -c foo
> Compiled from "foo.java"
> public class foo extends java.lang.Object{
> public static final boolean DEBUG;
>
> public foo();
>  Code:
>   0:   aload_0
>   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
>   4:   return
>
> public static boolean isDebug();
>  Code:
>   0:   ldc     #2; //String debug
>   2:   invokestatic    #3; //Method java/lang/System.getProperty:(Ljava/lang/String;)Ljava/lang/String;
>   5:   astore_0
>   6:   aload_0
>   7:   ifnull  12
>   10:  iconst_1
>   11:  ireturn
>   12:  iconst_0
>   13:  ireturn
>
> public static void main(java.lang.String[]);
>  Code:
>   0:   new     #4; //class foo
>   3:   dup
>   4:   invokespecial   #5; //Method "<init>":()V
>   7:   astore_1
>   8:   aload_1
>   9:   pop
>   10:  getstatic       #6; //Field DEBUG:Z
>   13:  ifeq    24
>   16:  getstatic       #7; //Field java/lang/System.out:Ljava/io/PrintStream;
>   19:  ldc     #8; //String I have a message to the user,
>   21:  invokevirtual   #9; //Method java/io/PrintStream.print:(Ljava/lang/String;)V
>   24:  getstatic       #7; //Field java/lang/System.out:Ljava/io/PrintStream;
>   27:  ldc     #10; //String hello
>   29:  invokevirtual   #9; //Method java/io/PrintStream.print:(Ljava/lang/String;)V
>   32:  aload_1
>   33:  pop
>   34:  getstatic       #6; //Field DEBUG:Z
>   37:  ifeq    48
>   40:  getstatic       #7; //Field java/lang/System.out:Ljava/io/PrintStream;
>   43:  ldc     #11; //String , i love you all,
>   45:  invokevirtual   #9; //Method java/io/PrintStream.print:(Ljava/lang/String;)V
>   48:  getstatic       #7; //Field java/lang/System.out:Ljava/io/PrintStream;
>   51:  ldc     #12; //String  world
>   53:  invokevirtual   #13; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
>   56:  return
>
> static {};
>  Code:
>   0:   invokestatic    #14; //Method isDebug:()Z
>   3:   putstatic       #6; //Field DEBUG:Z
>   6:   return
>
> }
>
>

Re: [Jamvm-general] Can JamVM optimize away static branches?

[Xerxes R. <xe...@za...>]

I have attached a slightly more interesting testcase.
This time the logic gets passed to JamVM.

Can JamVM optimize away these static branches when the public static final are set at runtime?

Cheers
Xerxes

xranby@xranby-ESPRIMO-P7935:~$ cat foo.java
public class foo {
    public static boolean isDebug(){
		String value = System.getProperty("debug");
		if(value!=null)
			return true;
		return false;
    }

    public static final boolean DEBUG=isDebug();

    public static void main(String[] args) {
	foo f = new foo();

	if (f.DEBUG) {
             System.out.print("I have a message to the user, ");
        }

        System.out.print("hello");

        if (f.DEBUG) {
             System.out.print(", i love you all,");
        }

	System.out.println(" world");
    }
}


xranby@xranby-ESPRIMO-P7935:~$ java foo
hello world
xranby@xranby-ESPRIMO-P7935:~$ java -Ddebug foo
I have a message to the user, hello, i love you all, world

xranby@xranby-ESPRIMO-P7935:~$ javap -c foo
Compiled from "foo.java"
public class foo extends java.lang.Object{
public static final boolean DEBUG;

public foo();
  Code:
   0:	aload_0
   1:	invokespecial	#1; //Method java/lang/Object."<init>":()V
   4:	return

public static boolean isDebug();
  Code:
   0:	ldc	#2; //String debug
   2:	invokestatic	#3; //Method java/lang/System.getProperty:(Ljava/lang/String;)Ljava/lang/String;
   5:	astore_0
   6:	aload_0
   7:	ifnull	12
   10:	iconst_1
   11:	ireturn
   12:	iconst_0
   13:	ireturn

public static void main(java.lang.String[]);
  Code:
   0:	new	#4; //class foo
   3:	dup
   4:	invokespecial	#5; //Method "<init>":()V
   7:	astore_1
   8:	aload_1
   9:	pop
   10:	getstatic	#6; //Field DEBUG:Z
   13:	ifeq	24
   16:	getstatic	#7; //Field java/lang/System.out:Ljava/io/PrintStream;
   19:	ldc	#8; //String I have a message to the user,
   21:	invokevirtual	#9; //Method java/io/PrintStream.print:(Ljava/lang/String;)V
   24:	getstatic	#7; //Field java/lang/System.out:Ljava/io/PrintStream;
   27:	ldc	#10; //String hello
   29:	invokevirtual	#9; //Method java/io/PrintStream.print:(Ljava/lang/String;)V
   32:	aload_1
   33:	pop
   34:	getstatic	#6; //Field DEBUG:Z
   37:	ifeq	48
   40:	getstatic	#7; //Field java/lang/System.out:Ljava/io/PrintStream;
   43:	ldc	#11; //String , i love you all,
   45:	invokevirtual	#9; //Method java/io/PrintStream.print:(Ljava/lang/String;)V
   48:	getstatic	#7; //Field java/lang/System.out:Ljava/io/PrintStream;
   51:	ldc	#12; //String  world
   53:	invokevirtual	#13; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   56:	return

static {};
  Code:
   0:	invokestatic	#14; //Method isDebug:()Z
   3:	putstatic	#6; //Field DEBUG:Z
   6:	return

}

Re: [Jamvm-general] Can JamVM optimize away static branches?

[Xerxes R. <xe...@za...>]

2012-02-23 15:21, David Griffiths skrev:
> The javac compiler optimizes them away before JamVM even gets a look in:
> 
> $ cat foo.java
> public class foo {
>     static final boolean DEBUG=false;
> 
>     public static void main(String[] args) {
>         if (DEBUG) {
>             System.out.println("hello");
>         }
>     }
> }
> 
> $ javap -c foo
> Compiled from "foo.java"
> public class foo extends java.lang.Object{
> static final boolean DEBUG;
> 
> public foo();
>   Code:
>    0:   aload_0
>    1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
>    4:   return
> 
> public static void main(java.lang.String[]);
>   Code:
>    0:   return
> 
> }
> 
> Cheers,
> 
> Dave

Ok! Thanks Dave for checking!

Cheers,
Xerxes

> 
> 
> On 23 February 2012 12:59, Xerxes Rånby <xe...@za... <mailto:xe...@za...>> wrote:
> 
>     Hi
> 
>     Inside the JogAmp JOGL bindings a lot of code look like this:
> 
>     static final boolean DEBUG=false;
>     if(DEBUG) { verbose stuff .. }
> 
>     Do JamVM optimize away these static branches?
> 
>     Cheers
>     Xerxes
> 
>     ------------------------------------------------------------------------------
>     Virtualization & Cloud Management Using Capacity Planning
>     Cloud computing makes use of virtualization - but cloud computing
>     also focuses on allowing computing to be delivered as a service.
>     http://www.accelacomm.com/jaw/sfnl/114/51521223/
>     _______________________________________________
>     Jamvm-general mailing list
>     Jam...@li... <mailto:Jam...@li...>
>     https://lists.sourceforge.net/lists/listinfo/jamvm-general
> 
> 

Re: [Jamvm-general] Can JamVM optimize away static branches?

[David G. <dav...@gm...>]

The javac compiler optimizes them away before JamVM even gets a look in:

$ cat foo.java
public class foo {
    static final boolean DEBUG=false;

    public static void main(String[] args) {
        if (DEBUG) {
            System.out.println("hello");
        }
    }
}

$ javap -c foo
Compiled from "foo.java"
public class foo extends java.lang.Object{
static final boolean DEBUG;

public foo();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public static void main(java.lang.String[]);
  Code:
   0:   return

}

Cheers,

Dave


On 23 February 2012 12:59, Xerxes Rånby <xe...@za...> wrote:

> Hi
>
> Inside the JogAmp JOGL bindings a lot of code look like this:
>
> static final boolean DEBUG=false;
> if(DEBUG) { verbose stuff .. }
>
> Do JamVM optimize away these static branches?
>
> Cheers
> Xerxes
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Jamvm-general mailing list
> Jam...@li...
> https://lists.sourceforge.net/lists/listinfo/jamvm-general
>

[Jamvm-general] Can JamVM optimize away static branches?

[Xerxes R. <xe...@za...>]

Hi

Inside the JogAmp JOGL bindings a lot of code look like this:

static final boolean DEBUG=false;
if(DEBUG) { verbose stuff .. }

Do JamVM optimize away these static branches?

Cheers
Xerxes

[Jamvm-general] Call for participation: Free Java @ FOSDEM 2012

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

We are pleased to announce the Call for Participation
in the FOSDEM 2012 Free Java DevRoom!

This marks the 9th year that the Free Java DevRoom
has been a part of FOSDEM. http://fosdem.org/2012/
Saturday 4th and Sunday 5th of February 2012
Brussels, Belgium

The Free Java DevRoom has become unique in that it
has attracted upstream, downstream, distrbutors and
and Free Software hackers together in one venue.
Topics range from the "deep technical" to
"deep community".

Join us for this year's theme: "Free Java Momentum"
Check out our wiki for more details on the conference:
http://wiki.debian.org/Java/DevJam/2012/Fosdem
And join the fre...@li... 
https://lists.fosdem.org/mailman/listinfo/freejava-devroom

Please submit one (or more) 30 minute talk proposal(s) by
the 30th of December 2011 to fo...@de....
A template for submitting a talk can be found at:
http://wiki.debian.org/Java/DevJam/2012/Fosdem/CallForParticipation

Please join us!

--The Free Java DevRoom Organizing Committee
  Andrew Haley, Red Hat
  Dalibor Topic, Oracle
  Dr Andrew John Hughes, Red Hat
  Mark Wielaard, IcedTea
  Sylvestre Ledru, Debian
  Tom Marble, Informatique


p.s. We had some nice media coverage last year...

FLOSS Weekly 152: FOSDEM
  http://twit.tv/floss152

Linux Outlaws 191 - Special: FOSDEM Coverage
  http://old.linuxoutlaws.com/podcast/191

Re: [Jamvm-general] [jamvm-general] Consider adding support for specifying memory in gigabyes via -msNg -msNG?

[Xerxes R. <xe...@za...>]

Hi Mark!

Thank you for the patch, I have included your GB memory option fix into
icedtea6, icedtea7 and icedtea 8:
http://icedtea.classpath.org/hg/icedtea/rev/9344881ce5c3

There was a typo in your last duplicate define of MB instead of a new
define of GB, I fixed this trivial error and have pushed your fix to
icedtea.

Cheers
Xerxes

mån 2011-09-26 klockan 16:56 +0800 skrev Mark David Dumlao:
> I'm sorry, that patch looked wrecked.
> 
> Here it is as an attachment.
> 
> On Mon, Sep 26, 2011 at 4:29 PM, Mark David Dumlao <mad...@gm...> wrote:
> > Hi!
> >
> > While using jamvm for icedtea, I noticed that some of my java apps
> > were failing terribly. After a grand time googling around for what
> > could have been causing the problems, I noticed that my java
> > environment did not accept memory heap arguments in terms of
> > gigabytes. That is, while for other java vms the following would have
> > worked:
> >
> >  java -Xmx1g -jar foo.jar
> >
> > Under jam I kept getting:
> >
> >   Invalid maximum heap size: -Xmx1g (min 4K)
> >   Could not create the Java virtual machine.
> >
> > It wasn't easy to google, but I noticed that size in gigabytes was
> > accepted by other vms, but not jam. On the other hand, jam would
> > happily accept size in megabytes even in excess of 1024.
> >

Re: [Jamvm-general] [jamvm-general] Consider adding support for specifying memory in gigabyes via -msNg -msNG?

[Mark D. D. <mad...@gm...>]

I'm sorry, that patch looked wrecked.

Here it is as an attachment.

On Mon, Sep 26, 2011 at 4:29 PM, Mark David Dumlao <mad...@gm...> wrote:
> Hi!
>
> While using jamvm for icedtea, I noticed that some of my java apps
> were failing terribly. After a grand time googling around for what
> could have been causing the problems, I noticed that my java
> environment did not accept memory heap arguments in terms of
> gigabytes. That is, while for other java vms the following would have
> worked:
>
>  java -Xmx1g -jar foo.jar
>
> Under jam I kept getting:
>
>   Invalid maximum heap size: -Xmx1g (min 4K)
>   Could not create the Java virtual machine.
>
> It wasn't easy to google, but I noticed that size in gigabytes was
> accepted by other vms, but not jam. On the other hand, jam would
> happily accept size in megabytes even in excess of 1024.
>
> I looked into the source of the jamvm from icedtea below:
> http://icedtea.classpath.org/download/drops/jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa.tar.gz
>
> and added the following lines to get it to accept gigabyte arguments.
>
> ===
> +diff -Nru jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa.orig/src/init.c
> jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa/src/init.c
> +--- jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa.orig/src/init.c
>  2011-03-25 17:36:12.000000000 +0800
> ++++ jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa/src/init.c
> 2011-06-16 01:44:48.879998232 +0800
> +@@ -123,6 +123,11 @@
> +         case '\0':
> +             break;
> +
> ++      case 'G':
> ++      case 'g':
> ++          n *= GB;
> ++          break;
> ++
> +         case 'M':
> +         case 'm':
> +             n *= MB;
> +diff -Nru jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa.orig/src/jam.h
> jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa/src/jam.h
> +--- jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa.orig/src/jam.h
>  2011-03-25 17:36:12.000000000 +0800
> ++++ jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa/src/jam.h
> 2011-06-16 01:42:30.688998249 +0800
> +@@ -734,6 +734,7 @@
> +
> + #define KB 1024
> + #define MB (KB*KB)
> ++#define GB (MB*KB)
> +
> + /* minimum allowable size of object heap */
> + #define MIN_HEAP 4*KB
> ===
>
> I haven't researched very well whether this is already part of
> upstream or not, as I only took this from the icedtea-6 tree.
> --
> This email is:    [ ] actionable   [ ] fyi        [x] social
> Response needed:  [ ] yes          [x] up to you  [ ] no
> Time-sensitive:   [ ] immediate    [ ] soon       [x] none
>



-- 
This email is:    [ ] actionable   [ ] fyi        [ ] social
Response needed:  [ ] yes          [ ] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [ ] none

[Jamvm-general] [jamvm-general] Consider adding support for specifying memory in gigabyes via -msNg -msNG?

[Mark D. D. <mad...@gm...>]

Hi!

While using jamvm for icedtea, I noticed that some of my java apps
were failing terribly. After a grand time googling around for what
could have been causing the problems, I noticed that my java
environment did not accept memory heap arguments in terms of
gigabytes. That is, while for other java vms the following would have
worked:

  java -Xmx1g -jar foo.jar

Under jam I kept getting:

   Invalid maximum heap size: -Xmx1g (min 4K)
   Could not create the Java virtual machine.

It wasn't easy to google, but I noticed that size in gigabytes was
accepted by other vms, but not jam. On the other hand, jam would
happily accept size in megabytes even in excess of 1024.

I looked into the source of the jamvm from icedtea below:
http://icedtea.classpath.org/download/drops/jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa.tar.gz

and added the following lines to get it to accept gigabyte arguments.

===
+diff -Nru jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa.orig/src/init.c
jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa/src/init.c
+--- jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa.orig/src/init.c
 2011-03-25 17:36:12.000000000 +0800
++++ jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa/src/init.c
2011-06-16 01:44:48.879998232 +0800
+@@ -123,6 +123,11 @@
+         case '\0':
+             break;
+
++      case 'G':
++      case 'g':
++          n *= GB;
++          break;
++
+         case 'M':
+         case 'm':
+             n *= MB;
+diff -Nru jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa.orig/src/jam.h
jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa/src/jam.h
+--- jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa.orig/src/jam.h
 2011-03-25 17:36:12.000000000 +0800
++++ jamvm-a95ca049d3bb257d730535a5d5ec3f73a943d0aa/src/jam.h
2011-06-16 01:42:30.688998249 +0800
+@@ -734,6 +734,7 @@
+
+ #define KB 1024
+ #define MB (KB*KB)
++#define GB (MB*KB)
+
+ /* minimum allowable size of object heap */
+ #define MIN_HEAP 4*KB
===

I haven't researched very well whether this is already part of
upstream or not, as I only took this from the icedtea-6 tree.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [Jamvm-general] Jenkins does not start on ARM+OpenJDK+JamVM

[Robert L. <rob...@gm...>]

Hi Xerxes,

On 17 August 2011 15:22, Xerxes Rånby <xe...@za...> wrote:
> ons 2011-08-17 klockan 12:45 +0100 skrev Robert Lougher:
>> On 17 August 2011 11:33, Robert Lougher <rob...@gm...> wrote:
>>
>> There's a bug in enclosingMethodInfo() (classlib/openjdk/reflect.c).
>> It should still return the enclosing class (in element 0 of the array)
>> even if there's no enclosing method.
>>
>> Here's a fixed version (see below).  It should work, but I'm unable to
>> check if it even compiles until tonight...
>>
>> > Rob.
>
> I want to confirm that this fix makes Jenkins work under JamVM!
>
> Cheers
> Xerxes
>
>

That's excellent news!  I'll check it in tonight.

Thanks,
Rob.

Re: [Jamvm-general] Jenkins does not start on ARM+OpenJDK+JamVM

[Xerxes R. <xe...@za...>]

ons 2011-08-17 klockan 12:45 +0100 skrev Robert Lougher:
> On 17 August 2011 11:33, Robert Lougher <rob...@gm...> wrote:
> > Hi Xerxes,
> >
> > On 17 August 2011 08:32, Xerxes Rånby <xe...@za...> wrote:
> >> Hi JamVM team!
> >>
> >> Forwarding a bug from ubuntu:
> >> https://bugs.launchpad.net/ubuntu/+source/jenkins-xstream/+bug/827463
> >> Jenkins fails to start becaused the OpenJDK bindings have missing
> >> implementation for java.lang.Class.getEnclosingClass().
> >>
> >
> > No, it's implemented.  Reflection support is somewhat more complicated
> > in OpenJDK than GNU Classpath, as responsibility is split between the
> > VM and the classlib (in GNU Classpath it's the VMs responsibility).
> >
> >  java.lang.Class.getEnclosingClass() eventually maps down to
> > JVM_GetEnclosingMethodInfo(), which returns a 3 element array
> > (enclosing class, method name and method type).
> >
> > There must be a bug somewhere.  I'll try and look at it tonight.
> >
> 
> There's a bug in enclosingMethodInfo() (classlib/openjdk/reflect.c).
> It should still return the enclosing class (in element 0 of the array)
> even if there's no enclosing method.
> 
> Here's a fixed version (see below).  It should work, but I'm unable to
> check if it even compiles until tonight...
> 
> Rob.
> 
> Object *enclosingMethodInfo(Class *class) {
>     ClassBlock *cb = CLASS_CB(class);
>     Object *info = NULL;
> 
>     if(cb->enclosing_class) {
>         Class *enc_class = resolveClass(class, cb->enclosing_class,
>                                         TRUE, FALSE);
> 
>         if(enc_class != NULL) {
>             Class *ary_class = findArrayClass(SYMBOL(array_java_lang_Object));
> 
>             if(ary_class != NULL) {
>                 info = allocArray(ary_class, 3, sizeof(Object*));
> 
>                 if(info != NULL) {
>                     ARRAY_DATA(info, Object*)[0] = enc_class;
> 
>                     if(cb->enclosing_method) {
>                         ConstantPool *cp = &cb->constant_pool;
>                         char *methodname = CP_UTF8(cp, CP_NAME_TYPE_NAME(cp,
>                                                        cb->enclosing_method));
>                         char *methodtype = CP_UTF8(cp, CP_NAME_TYPE_TYPE(cp,
>                                                        cb->enclosing_method));
>                         Object *name = createString(methodname);
>                         Object *type = createString(methodtype);
> 
>                         if(name == NULL || type == NULL)
>                             return NULL;
> 
>                         ARRAY_DATA(info, Object*)[1] = name;
>                         ARRAY_DATA(info, Object*)[2] = type;
>                     }
>                 }
>             }
>         }
>     }
> 
>     return info;
> }
> 
> > Rob.

I want to confirm that this fix makes Jenkins work under JamVM!

Cheers
Xerxes

Re: [Jamvm-general] Jenkins does not start on ARM+OpenJDK+JamVM

[Robert L. <rob...@gm...>]

On 17 August 2011 11:33, Robert Lougher <rob...@gm...> wrote:
> Hi Xerxes,
>
> On 17 August 2011 08:32, Xerxes Rånby <xe...@za...> wrote:
>> Hi JamVM team!
>>
>> Forwarding a bug from ubuntu:
>> https://bugs.launchpad.net/ubuntu/+source/jenkins-xstream/+bug/827463
>> Jenkins fails to start becaused the OpenJDK bindings have missing
>> implementation for java.lang.Class.getEnclosingClass().
>>
>
> No, it's implemented.  Reflection support is somewhat more complicated
> in OpenJDK than GNU Classpath, as responsibility is split between the
> VM and the classlib (in GNU Classpath it's the VMs responsibility).
>
>  java.lang.Class.getEnclosingClass() eventually maps down to
> JVM_GetEnclosingMethodInfo(), which returns a 3 element array
> (enclosing class, method name and method type).
>
> There must be a bug somewhere.  I'll try and look at it tonight.
>

There's a bug in enclosingMethodInfo() (classlib/openjdk/reflect.c).
It should still return the enclosing class (in element 0 of the array)
even if there's no enclosing method.

Here's a fixed version (see below).  It should work, but I'm unable to
check if it even compiles until tonight...

Rob.

Object *enclosingMethodInfo(Class *class) {
    ClassBlock *cb = CLASS_CB(class);
    Object *info = NULL;

    if(cb->enclosing_class) {
        Class *enc_class = resolveClass(class, cb->enclosing_class,
                                        TRUE, FALSE);

        if(enc_class != NULL) {
            Class *ary_class = findArrayClass(SYMBOL(array_java_lang_Object));

            if(ary_class != NULL) {
                info = allocArray(ary_class, 3, sizeof(Object*));

                if(info != NULL) {
                    ARRAY_DATA(info, Object*)[0] = enc_class;

                    if(cb->enclosing_method) {
                        ConstantPool *cp = &cb->constant_pool;
                        char *methodname = CP_UTF8(cp, CP_NAME_TYPE_NAME(cp,
                                                       cb->enclosing_method));
                        char *methodtype = CP_UTF8(cp, CP_NAME_TYPE_TYPE(cp,
                                                       cb->enclosing_method));
                        Object *name = createString(methodname);
                        Object *type = createString(methodtype);

                        if(name == NULL || type == NULL)
                            return NULL;

                        ARRAY_DATA(info, Object*)[1] = name;
                        ARRAY_DATA(info, Object*)[2] = type;
                    }
                }
            }
        }
    }

    return info;
}

> Rob.
>
>> I noticed that the gnuclasspath bindings have support.
>> (oneiric)xranby@ac100:~/icedtea6-jamvm/jamvm/jamvm/src/classlib$ grep
>> getEnclosing -r *
>> gnuclasspath/reflect.c:Class *getEnclosingClass(Class *class) {
>> gnuclasspath/reflect.c:MethodBlock *getEnclosingMethod(Class *class) {
>> gnuclasspath/reflect.c:    Class *enclosing_class =
>> getEnclosingClass(class);
>> gnuclasspath/reflect.c:Object *getEnclosingMethodObject(Class *class) {
>> gnuclasspath/reflect.c:    MethodBlock *mb = getEnclosingMethod(class);
>> gnuclasspath/reflect.c:Object *getEnclosingConstructorObject(Class *class) {
>> gnuclasspath/reflect.c:    MethodBlock *mb = getEnclosingMethod(class);
>> gnuclasspath/natives.c:uintptr_t *getEnclosingClass0(Class *class,
>> MethodBlock *mb,
>> gnuclasspath/natives.c:    *ostack++ = (uintptr_t) getEnclosingClass(clazz);
>> gnuclasspath/natives.c:uintptr_t *getEnclosingMethod0(Class *class,
>> MethodBlock *mb,
>> gnuclasspath/natives.c:    *ostack++ = (uintptr_t)
>> getEnclosingMethodObject(clazz);
>> gnuclasspath/natives.c:uintptr_t *getEnclosingConstructor(Class *class,
>> MethodBlock *mb,
>> gnuclasspath/natives.c:    *ostack++ = (uintptr_t)
>> getEnclosingConstructorObject(clazz);
>> gnuclasspath/natives.c:    {"getEnclosingClass",           NULL,
>> getEnclosingClass0},
>> gnuclasspath/natives.c:    {"getEnclosingMethod",          NULL,
>> getEnclosingMethod0},
>> gnuclasspath/natives.c:    {"getEnclosingConstructor",     NULL,
>> getEnclosingConstructor},
>> gnuclasspath/lib/java/lang/VMClass.java:    Class enclosingClass =
>> getEnclosingClass(klass);
>> gnuclasspath/lib/java/lang/VMClass.java:  static native Class
>> getEnclosingClass(Class klass);
>> gnuclasspath/lib/java/lang/VMClass.java:  static native Constructor
>> getEnclosingConstructor(Class klass);
>> gnuclasspath/lib/java/lang/VMClass.java:  static native Method
>> getEnclosingMethod(Class klass);
>>
>> Cheers
>> Xerxes
>>
>

Re: [Jamvm-general] Jenkins does not start on ARM+OpenJDK+JamVM

[Robert L. <rob...@gm...>]

Hi Xerxes,

On 17 August 2011 08:32, Xerxes Rånby <xe...@za...> wrote:
> Hi JamVM team!
>
> Forwarding a bug from ubuntu:
> https://bugs.launchpad.net/ubuntu/+source/jenkins-xstream/+bug/827463
> Jenkins fails to start becaused the OpenJDK bindings have missing
> implementation for java.lang.Class.getEnclosingClass().
>

No, it's implemented.  Reflection support is somewhat more complicated
in OpenJDK than GNU Classpath, as responsibility is split between the
VM and the classlib (in GNU Classpath it's the VMs responsibility).

 java.lang.Class.getEnclosingClass() eventually maps down to
JVM_GetEnclosingMethodInfo(), which returns a 3 element array
(enclosing class, method name and method type).

There must be a bug somewhere.  I'll try and look at it tonight.

Rob.

> I noticed that the gnuclasspath bindings have support.
> (oneiric)xranby@ac100:~/icedtea6-jamvm/jamvm/jamvm/src/classlib$ grep
> getEnclosing -r *
> gnuclasspath/reflect.c:Class *getEnclosingClass(Class *class) {
> gnuclasspath/reflect.c:MethodBlock *getEnclosingMethod(Class *class) {
> gnuclasspath/reflect.c:    Class *enclosing_class =
> getEnclosingClass(class);
> gnuclasspath/reflect.c:Object *getEnclosingMethodObject(Class *class) {
> gnuclasspath/reflect.c:    MethodBlock *mb = getEnclosingMethod(class);
> gnuclasspath/reflect.c:Object *getEnclosingConstructorObject(Class *class) {
> gnuclasspath/reflect.c:    MethodBlock *mb = getEnclosingMethod(class);
> gnuclasspath/natives.c:uintptr_t *getEnclosingClass0(Class *class,
> MethodBlock *mb,
> gnuclasspath/natives.c:    *ostack++ = (uintptr_t) getEnclosingClass(clazz);
> gnuclasspath/natives.c:uintptr_t *getEnclosingMethod0(Class *class,
> MethodBlock *mb,
> gnuclasspath/natives.c:    *ostack++ = (uintptr_t)
> getEnclosingMethodObject(clazz);
> gnuclasspath/natives.c:uintptr_t *getEnclosingConstructor(Class *class,
> MethodBlock *mb,
> gnuclasspath/natives.c:    *ostack++ = (uintptr_t)
> getEnclosingConstructorObject(clazz);
> gnuclasspath/natives.c:    {"getEnclosingClass",           NULL,
> getEnclosingClass0},
> gnuclasspath/natives.c:    {"getEnclosingMethod",          NULL,
> getEnclosingMethod0},
> gnuclasspath/natives.c:    {"getEnclosingConstructor",     NULL,
> getEnclosingConstructor},
> gnuclasspath/lib/java/lang/VMClass.java:    Class enclosingClass =
> getEnclosingClass(klass);
> gnuclasspath/lib/java/lang/VMClass.java:  static native Class
> getEnclosingClass(Class klass);
> gnuclasspath/lib/java/lang/VMClass.java:  static native Constructor
> getEnclosingConstructor(Class klass);
> gnuclasspath/lib/java/lang/VMClass.java:  static native Method
> getEnclosingMethod(Class klass);
>
> Cheers
> Xerxes
>

[Jamvm-general] Jenkins does not start on ARM+OpenJDK+JamVM

[Xerxes R. <xe...@za...>]

Hi JamVM team!

Forwarding a bug from ubuntu:
https://bugs.launchpad.net/ubuntu/+source/jenkins-xstream/+bug/827463
Jenkins fails to start becaused the OpenJDK bindings have missing implementation for 
java.lang.Class.getEnclosingClass().

I noticed that the gnuclasspath bindings have support.
(oneiric)xranby@ac100:~/icedtea6-jamvm/jamvm/jamvm/src/classlib$ grep getEnclosing -r *
gnuclasspath/reflect.c:Class *getEnclosingClass(Class *class) {
gnuclasspath/reflect.c:MethodBlock *getEnclosingMethod(Class *class) {
gnuclasspath/reflect.c:    Class *enclosing_class = getEnclosingClass(class);
gnuclasspath/reflect.c:Object *getEnclosingMethodObject(Class *class) {
gnuclasspath/reflect.c:    MethodBlock *mb = getEnclosingMethod(class);
gnuclasspath/reflect.c:Object *getEnclosingConstructorObject(Class *class) {
gnuclasspath/reflect.c:    MethodBlock *mb = getEnclosingMethod(class);
gnuclasspath/natives.c:uintptr_t *getEnclosingClass0(Class *class, MethodBlock *mb,
gnuclasspath/natives.c:    *ostack++ = (uintptr_t) getEnclosingClass(clazz);
gnuclasspath/natives.c:uintptr_t *getEnclosingMethod0(Class *class, MethodBlock *mb,
gnuclasspath/natives.c:    *ostack++ = (uintptr_t) getEnclosingMethodObject(clazz);
gnuclasspath/natives.c:uintptr_t *getEnclosingConstructor(Class *class, MethodBlock *mb,
gnuclasspath/natives.c:    *ostack++ = (uintptr_t) getEnclosingConstructorObject(clazz);
gnuclasspath/natives.c:    {"getEnclosingClass",           NULL, getEnclosingClass0},
gnuclasspath/natives.c:    {"getEnclosingMethod",          NULL, getEnclosingMethod0},
gnuclasspath/natives.c:    {"getEnclosingConstructor",     NULL, getEnclosingConstructor},
gnuclasspath/lib/java/lang/VMClass.java:    Class enclosingClass = getEnclosingClass(klass);
gnuclasspath/lib/java/lang/VMClass.java:  static native Class getEnclosingClass(Class klass);
gnuclasspath/lib/java/lang/VMClass.java:  static native Constructor 
getEnclosingConstructor(Class klass);
gnuclasspath/lib/java/lang/VMClass.java:  static native Method getEnclosingMethod(Class 
klass);

Cheers
Xerxes

[Jamvm-general] FTBFS on IA32 using GCC version < 4.5

[Xerxes R. <xe...@za...>]

Hi,

When building JamVM on IA32 older gcc version (GCC < 4.5) then JamVM
fails to build from source with the following error:

make[5]: Entering directory `/home/xerxes/jamvm/src/os/linux/i386'
/bin/bash ../../../../libtool --tag=CC   --mode=compile gcc
-DHAVE_CONFIG_H -I. -I../../../../src  -I../../../../src
-I../../../../src   -g -O2 -MT dll_md.lo -MD -MP -MF .deps/dll_md.Tpo -c
-o dll_md.lo dll_md.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../../src
-I../../../../src -I../../../../src -g -O2 -MT dll_md.lo -MD -MP
-MF .deps/dll_md.Tpo -c dll_md.c  -fPIC -DPIC -o .libs/dll_md.o
dll_md.c: In function 'callJNIMethod':
dll_md.c:68: error: expected string literal before ')' token
make[5]: *** [dll_md.lo] Error 1 

The attached fix and makes JamVM build from source again by removing the
empty clobber list part of the ASM statement.

Cheers
Xerxes

Re: [Jamvm-general] JamVM+GNU Classpath; -classpath option broken

[Dr A. J. H. <ah...@re...>]

On 00:45 Tue 02 Aug     , Robert Lougher wrote:
> Hi,
> 
> On 1 August 2011 23:50, Dr Andrew John Hughes <ah...@re...> wrote:
> > As of:
> >
> > commit 1b248439e88ae6cbd1471addc49e2666b8964ced
> > Author: Robert Lougher <ro...@ja...>
> > Date:   Fri May 6 02:30:54 2011 +0100
> >
> >    Unify command line options parsing
> >
> >    JamVM has two sets of options parsing.  The first is in the jamvm
> >    executable that is the VM entry-point when used with GNU Classpath
> >    (with GNU Classpath, JamVM is linked into a single standalone
> >    executable, as well as libjvm.so).
> >
> >    The other is the options parsing within the JNI invocation API.
> >    This entry-point is used when the VM is linked into another
> >    process, and the VM is created via JNI.  This is the standard
> >    entry point when used with OpenJDK/IcedTea.  Here, the VM
> >    is started via a small launcher executable, which handles command
> >    line parsing, passing arguments to the JNI invocation API.
> >
> >    Within these two routines, many of the options can be handled
> >    identically.  However, small differences has made separating these
> >    options out into a common routine difficult.  These issues have
> >    now been resolved and a common routine for parsing is now used.
> >
> >    The motivation for the change is the OpenJDK port.  In the past,
> >    the JNI invocation API only handled a subset of the special -X
> >    options, but with the OpenJDK port, this is now the main entry-
> >    point into the VM.
> >
> >    Signed-off-by: Robert Lougher <ro...@ja...>
> >
> > JamVM+GNU Classpath seems to be broken for any practical use as you
> > can no longer pass it -classpath or -cp (even though the help still
> > says you can!)
> >
> > It seems this was removed:
> >
> > -        } else if(strcmp(argv[i], "-classpath") == 0 ||
> > -                  strcmp(argv[i], "-cp") == 0) {
> > -
> > -            if(i == argc - 1) {
> > -                printf("%s : missing path list\n", argv[i]);
> > -                goto exit;
> > -            }
> > -            args->classpath = argv[++i];
> > -
> >
> > but nothing put in place of it.
> >
> 
> You're right.  It was in some code that got moved.  Now fixed!
> 

Thanks for the quick fix.  JamVM+GNU Classpath now seems to be compiling
OpenJDK in IcedTea7 just fine :-)

> Thanks,
> Rob.
> 
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: [Jamvm-general] Jamvm seg faults on Mips ( Big endian )

[Robert L. <rob...@gm...>]

Hi,

On 2 August 2011 09:50, JediKnight <ver...@ya...> wrote:
>
> Hi Rob,
>
> Any pointers how to debug this ?
>

Debugging a JVM is not easy.  First thing to always do is disable the
(code-copying) JIT.  This is for two reasons.  If it now works the
problem is likely to be invalid code from the JIT.  You now have a
really tough debugging task!

If it still doesn't work the problem is in the rest of the VM.
Turning off the JIT makes debugging far easier, as the PC now points
to compiled C code rather than generated code, which confuses the
debugger.

On MIPS, the JIT is off by default in 1.5.4.  It is on in 1.6.0.

./configure --disable-int-inlining

Now run the executable in gdb.  Before you run anything you want to do:

handle SIGUSR1 nostop pass noprint

Otherwise gdb will stop whenever a thread is suspended by the VM (e.g.
for garbage collection).

Now run your program.  It should stop when the segv occurs, and you
should be able to get a backtrace.

This should be enough for getting on with.  You'll probably want to
poke about a bit, and print the values of various variables.  By
default JamVM is built with -O2 -g.  The -O2 can make debugging
harder, as some values will be optimised out by the compiler.  So at
this stage you might like to try disabling optimisation, e.g.:

./configure --disable-int-inlining CFLAGS=-g

Of course, everything will run much slower.

Rob.

> /JediKnight
>
> --
> View this message in context: http://old.nabble.com/Jamvm-seg-faults-on-Mips-%28-Big-endian-%29-tp32089143p32176070.html
> Sent from the JamVM mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Jamvm-general mailing list
> Jam...@li...
> https://lists.sourceforge.net/lists/listinfo/jamvm-general
>

Re: [Jamvm-general] Jamvm seg faults on Mips ( Big endian )

[JediKnight <ver...@ya...>]

Hi Rob,

Any pointers how to debug this ?

/JediKnight

-- 
View this message in context: http://old.nabble.com/Jamvm-seg-faults-on-Mips-%28-Big-endian-%29-tp32089143p32176070.html
Sent from the JamVM mailing list archive at Nabble.com.

Re: [Jamvm-general] JamVM+GNU Classpath; -classpath option broken

[Robert L. <rob...@gm...>]

Hi,

On 1 August 2011 23:50, Dr Andrew John Hughes <ah...@re...> wrote:
> As of:
>
> commit 1b248439e88ae6cbd1471addc49e2666b8964ced
> Author: Robert Lougher <ro...@ja...>
> Date:   Fri May 6 02:30:54 2011 +0100
>
>    Unify command line options parsing
>
>    JamVM has two sets of options parsing.  The first is in the jamvm
>    executable that is the VM entry-point when used with GNU Classpath
>    (with GNU Classpath, JamVM is linked into a single standalone
>    executable, as well as libjvm.so).
>
>    The other is the options parsing within the JNI invocation API.
>    This entry-point is used when the VM is linked into another
>    process, and the VM is created via JNI.  This is the standard
>    entry point when used with OpenJDK/IcedTea.  Here, the VM
>    is started via a small launcher executable, which handles command
>    line parsing, passing arguments to the JNI invocation API.
>
>    Within these two routines, many of the options can be handled
>    identically.  However, small differences has made separating these
>    options out into a common routine difficult.  These issues have
>    now been resolved and a common routine for parsing is now used.
>
>    The motivation for the change is the OpenJDK port.  In the past,
>    the JNI invocation API only handled a subset of the special -X
>    options, but with the OpenJDK port, this is now the main entry-
>    point into the VM.
>
>    Signed-off-by: Robert Lougher <ro...@ja...>
>
> JamVM+GNU Classpath seems to be broken for any practical use as you
> can no longer pass it -classpath or -cp (even though the help still
> says you can!)
>
> It seems this was removed:
>
> -        } else if(strcmp(argv[i], "-classpath") == 0 ||
> -                  strcmp(argv[i], "-cp") == 0) {
> -
> -            if(i == argc - 1) {
> -                printf("%s : missing path list\n", argv[i]);
> -                goto exit;
> -            }
> -            args->classpath = argv[++i];
> -
>
> but nothing put in place of it.
>

You're right.  It was in some code that got moved.  Now fixed!

Thanks,
Rob.

> I've just updated to the git repo from the old CVS repo. and was trying
> to setup a JamVM-based GNU Classpath JDK for building IcedTea.  But with
> this bug I can't even run the GNU Classpath tools using JamVM.
> --
> Andrew :)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and IcedTea
> http://www.gnu.org/software/classpath
> http://icedtea.classpath.org
> PGP Key: F5862A37 (https://keys.indymedia.org/)
> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Jamvm-general mailing list
> Jam...@li...
> https://lists.sourceforge.net/lists/listinfo/jamvm-general
>

[Jamvm-general] JamVM+GNU Classpath; -classpath option broken

[Dr A. J. H. <ah...@re...>]

As of:

commit 1b248439e88ae6cbd1471addc49e2666b8964ced
Author: Robert Lougher <ro...@ja...>
Date:   Fri May 6 02:30:54 2011 +0100

    Unify command line options parsing
    
    JamVM has two sets of options parsing.  The first is in the jamvm
    executable that is the VM entry-point when used with GNU Classpath
    (with GNU Classpath, JamVM is linked into a single standalone
    executable, as well as libjvm.so).
    
    The other is the options parsing within the JNI invocation API.
    This entry-point is used when the VM is linked into another
    process, and the VM is created via JNI.  This is the standard
    entry point when used with OpenJDK/IcedTea.  Here, the VM
    is started via a small launcher executable, which handles command
    line parsing, passing arguments to the JNI invocation API.
    
    Within these two routines, many of the options can be handled
    identically.  However, small differences has made separating these
    options out into a common routine difficult.  These issues have
    now been resolved and a common routine for parsing is now used.
    
    The motivation for the change is the OpenJDK port.  In the past,
    the JNI invocation API only handled a subset of the special -X
    options, but with the OpenJDK port, this is now the main entry-
    point into the VM.
    
    Signed-off-by: Robert Lougher <ro...@ja...>

JamVM+GNU Classpath seems to be broken for any practical use as you
can no longer pass it -classpath or -cp (even though the help still
says you can!)

It seems this was removed:

-        } else if(strcmp(argv[i], "-classpath") == 0 ||
-                  strcmp(argv[i], "-cp") == 0) {
-
-            if(i == argc - 1) {
-                printf("%s : missing path list\n", argv[i]);
-                goto exit;
-            }
-            args->classpath = argv[++i];
-

but nothing put in place of it.

I've just updated to the git repo from the old CVS repo. and was trying
to setup a JamVM-based GNU Classpath JDK for building IcedTea.  But with
this bug I can't even run the GNU Classpath tools using JamVM.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: [Jamvm-general] Jamvm seg faults on Mips ( Big endian )

[JediKnight <ver...@ya...>]

Hi, 

Applogies for the spam. 

Was trying to post a message and i got an HTTP error 500 leading me to
believe that the message was not posted. As i result i posted several times. 

Mods: can you remove multiple copies of the same message.

/JediKnight.

-- 
View this message in context: http://old.nabble.com/Jamvm-seg-faults-on-Mips-%28-Big-endian-%29-tp32089143p32159613.html
Sent from the JamVM mailing list archive at Nabble.com.