sablevm-developer

[Sablevm-developer] JGFSyncBench fails

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

Hi,

I'm trying to get some basic multithreading benchmarks to run with 
recent stagings (sablevm@1503 + sablevm-classpath@1509), but a seemingly 
simple one always fails (it works with Sun's java-1.4.1).  I did not try 
older builds with this benchmark, but Bruno's RollerCoaster was failing 
with the switch interpreter as well and that was why I upgraded to 
staging (it no longer fails).

I'm trying to run JGFSyncBench in section1 of the multithreaded Java 
Grande Forum Benchmarks:

http://www.epcc.ed.ac.uk/computing/research_activities/java_grande/index_1.html

I would like to try and fix this bug, but seeing as I have until now 
been primarily fixing problems with my own stuff, I need some pointers 
as to what needs to be fixed (I am not familiar with the written code, 
and concurrency problems are not exactly fun to debug), confirmation 
that it also fails for you, at least some of the time, and maybe 
suggestions as to how to fix this (if you have them).  Other mt 
benchmarks seem to be working okay (not all with my spmt stuff, e.g. 
RollerCoaster still fails, but that's possibly a separate issue).

The JGFSyncBench benchmark sets up an array of threads, and then calls a 
synchronized method to update a counter inside them (source is 
uncommented but I couldn't see any problems with it).

Cheers,
Chris

=============================================================

$ wget 
http://www.epcc.ed.ac.uk/computing/research_activities/java_grande/threads/jgf_threadv1.0.tar.gz
$ tar xvfz jgf_threadv1.0.tar.gz
$ cd threadv1.0  # not 100% sure about dir name, I changed mine
$ cd jgfutil
$ javac *.*      # or gcj-3.3.2
$ cd ..
$ cd section1
$ javac *.*      # or gcj-3.3.2
$ java -cp .:..:/usr/localcc/pkgs/j2sdk1.4.1/jre/lib/rt.jar JGFSyncBench

The no of threads has not been specified, defaulting to 1

Java Grande Forum Thread Benchmark Suite - Version 1.0 - Section 1
Executing on 1 thread

Section1:Sync:Method                            81471.58 
(synchronisations/s)
Section1:Sync:Object                            79458.69 
(synchronisations/s)

$ sablevm-staging-switch -c .:.. -Y JGFSyncBench

The no of threads has not been specified, defaulting to 1

Java Grande Forum Thread Benchmark Suite - Version 1.0 - Section 1
Executing on 1 thread

java.lang.NullPointerException
    at SyncMethodRunner.run (JGFSyncBench.java:166)
    at JGFSyncBench.JGFrun (JGFSyncBench.java:64)
    at JGFSyncBench.main (JGFSyncBench.java:133)
    at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
    at java.lang.VirtualMachine.main (VirtualMachine.java:88)

$ sablevm-staging-switch -c .:.. -Y JGFSyncBench

The no of threads has not been specified, defaulting to 1

Java Grande Forum Thread Benchmark Suite - Version 1.0 - Section 1
Executing on 1 thread

Exception in thread "Thread-10" java.lang.NullPointerException
    at SyncMethodRunner.run (JGFSyncBench.java:166)
    at java.lang.Thread.run (Thread.java:455)
    at java.lang.VMThread.callRun (VMThread.java:116)
    at java.lang.Thread.callRun (Thread.java:333)
    at java.lang.VirtualMachine.runThread (VirtualMachine.java:117)
java.lang.NullPointerException
    at SyncMethodRunner.run (JGFSyncBench.java:166)
    at JGFSyncBench.JGFrun (JGFSyncBench.java:64)
    at JGFSyncBench.main (JGFSyncBench.java:133)
    at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
    at java.lang.VirtualMachine.main (VirtualMachine.java:88)

---> it's different output each time as well, which makes this messier.

Re: [Sablevm-developer] JGFSyncBench fails

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

Hi Chris,

Did you ran it with --enable-debugging?
Or at least without signals for execption?

If not, run it without signals for exceptions.  (seg faults are
interpreted as NullPointerEx).

If it seg faults you can use gdb to find location.


David

On Fri, Jan 30, 2004 at 12:46:14AM -0500, Chris Pickett wrote:
> Hi,
>=20
> I'm trying to get some basic multithreading benchmarks to run with=20
> recent stagings (sablevm@1503 + sablevm-classpath@1509), but a seemingl=
y=20
> simple one always fails (it works with Sun's java-1.4.1).  I did not tr=
y=20
> older builds with this benchmark, but Bruno's RollerCoaster was failing=
=20
> with the switch interpreter as well and that was why I upgraded to=20
> staging (it no longer fails).
>=20
> I'm trying to run JGFSyncBench in section1 of the multithreaded Java=20
> Grande Forum Benchmarks:
>=20
> http://www.epcc.ed.ac.uk/computing/research_activities/java_grande/inde=
x_1.html
>=20
> I would like to try and fix this bug, but seeing as I have until now=20
> been primarily fixing problems with my own stuff, I need some pointers=20
> as to what needs to be fixed (I am not familiar with the written code,=20
> and concurrency problems are not exactly fun to debug), confirmation=20
> that it also fails for you, at least some of the time, and maybe=20
> suggestions as to how to fix this (if you have them).  Other mt=20
> benchmarks seem to be working okay (not all with my spmt stuff, e.g.=20
> RollerCoaster still fails, but that's possibly a separate issue).
>=20
> The JGFSyncBench benchmark sets up an array of threads, and then calls =
a=20
> synchronized method to update a counter inside them (source is=20
> uncommented but I couldn't see any problems with it).
>=20
> Cheers,
> Chris
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> $ wget=20
> http://www.epcc.ed.ac.uk/computing/research_activities/java_grande/thre=
ads/jgf_threadv1.0.tar.gz
> $ tar xvfz jgf_threadv1.0.tar.gz
> $ cd threadv1.0  # not 100% sure about dir name, I changed mine
> $ cd jgfutil
> $ javac *.*      # or gcj-3.3.2
> $ cd ..
> $ cd section1
> $ javac *.*      # or gcj-3.3.2
> $ java -cp .:..:/usr/localcc/pkgs/j2sdk1.4.1/jre/lib/rt.jar JGFSyncBenc=
h
>=20
> The no of threads has not been specified, defaulting to 1
>=20
> Java Grande Forum Thread Benchmark Suite - Version 1.0 - Section 1
> Executing on 1 thread
>=20
> Section1:Sync:Method                            81471.58=20
> (synchronisations/s)
> Section1:Sync:Object                            79458.69=20
> (synchronisations/s)
>=20
> $ sablevm-staging-switch -c .:.. -Y JGFSyncBench
>=20
> The no of threads has not been specified, defaulting to 1
>=20
> Java Grande Forum Thread Benchmark Suite - Version 1.0 - Section 1
> Executing on 1 thread
>=20
> java.lang.NullPointerException
>    at SyncMethodRunner.run (JGFSyncBench.java:166)
>    at JGFSyncBench.JGFrun (JGFSyncBench.java:64)
>    at JGFSyncBench.main (JGFSyncBench.java:133)
>    at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
>    at java.lang.VirtualMachine.main (VirtualMachine.java:88)
>=20
> $ sablevm-staging-switch -c .:.. -Y JGFSyncBench
>=20
> The no of threads has not been specified, defaulting to 1
>=20
> Java Grande Forum Thread Benchmark Suite - Version 1.0 - Section 1
> Executing on 1 thread
>=20
> Exception in thread "Thread-10" java.lang.NullPointerException
>    at SyncMethodRunner.run (JGFSyncBench.java:166)
>    at java.lang.Thread.run (Thread.java:455)
>    at java.lang.VMThread.callRun (VMThread.java:116)
>    at java.lang.Thread.callRun (Thread.java:333)
>    at java.lang.VirtualMachine.runThread (VirtualMachine.java:117)
> java.lang.NullPointerException
>    at SyncMethodRunner.run (JGFSyncBench.java:166)
>    at JGFSyncBench.JGFrun (JGFSyncBench.java:64)
>    at JGFSyncBench.main (JGFSyncBench.java:133)
>    at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
>    at java.lang.VirtualMachine.main (VirtualMachine.java:88)
>=20
> ---> it's different output each time as well, which makes this messier.
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> 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] JGFSyncBench fails

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

David B=E9langer wrote:

> Hi Chris,
>=20
> Did you ran it with --enable-debugging?
> Or at least without signals for execption?
>=20
> If not, run it without signals for exceptions.  (seg faults are
> interpreted as NullPointerEx).
>=20
> If it seg faults you can use gdb to find location.

Hi David,

My shell wasn't creating core files, and so I wasn't using gdb.=20
'ulimitb -c unlimited' fixed that.

It segfaults inside pthread_mutex_lock(), called when inflating a thin=20
lock, inside _svmf_enter_object_monitor(), called from INVOKEVIRTUAL
(the benchmark tests calling a synchronized method over and over).

I've read through all the locking stuff, but I can't see any errors in=20
the logic.  I was seeing similar things with mtrt and my spmt version:=20
there there was a concurrency error restoring the thread state (which=20
should now be safe!), if the other thread was in the middle of a=20
MONITORENTER.  Maybe there's a bug in Etienne's locking algorithm?

I don't have much experience with gdb, so I don't know if it can help=20
any more.  I don't think inserting breakpoints is going to do much,=20
since it fails randomly in a commonly called function.  I suppose it=20
would be useful to know why pthread_mutex_lock() causes a segfault --=20
but I can't even find pthread.c on the school machines.

http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_loc=
k.html

At the same time, I don't know what could be wrong with the locking=20
code, so ... I still need more pointers, if you've got them.  gdb output =

follows, if it's any help . . .

Can you (or somebody else) confirm the failure?

Cheers, and thanks,
Chris

P.S.  Again, this is a problem on uniprocessors.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


#0  0x400bbe90 in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0x4009a0a2 in _svmf_enter_object_monitor (env=3D0x8068e50,=20
instance=3D0x402a6014)
     at thread.c:863
#2  0x4007035d in _svmf_interpreter (_env=3D0x8068e50) at=20
instructions_switch.c:15949
#3  0x40028c50 in _svmh_invoke_static_virtualmachine_runthread=20
(env=3D0x8068e50)
     at method_invoke.c:5065
#4  0x4001f208 in _svmf_thread_start (_env=3D0x8068e50) at thread.c:1195
#5  0x400bb0ba in pthread_start_thread () from /lib/libpthread.so.0
#6  0x401dcd6a in clone () from /lib/libc.so.6
(gdb) info f
Stack level 0, frame at 0xbf3ff59c:
  eip =3D 0x400bbe90 in pthread_mutex_lock; saved eip 0x4009a0a2
  called by frame at 0xbf3ff5ec
  Arglist at 0xbf3ff594, args:
  Locals at 0xbf3ff594, Previous frame's sp is 0xbf3ff59c
  Saved registers:
   ebx at 0xbf3ff57c, ebp at 0xbf3ff594, esi at 0xbf3ff580, edi at=20
0xbf3ff584,
   eip at 0xbf3ff598
(gdb) up
#1  0x4009a0a2 in _svmf_enter_object_monitor (env=3D0x8068e50,=20
instance=3D0x402a6014)
     at thread.c:863
863               _svmm_mutex_lock (owner->contention.owner.mutex);
(gdb) info f
Stack level 1, frame at 0xbf3ff5ec:
  eip =3D 0x4009a0a2 in _svmf_enter_object_monitor (thread.c:863);
     saved eip 0x4007035d
  called by frame at 0xbf3ffaac, caller of frame at 0xbf3ff59c
  source language c.
  Arglist at 0xbf3ff5e4, args: env=3D0x8068e50, instance=3D0x402a6014
  Locals at 0xbf3ff5e4, Previous frame's sp is 0xbf3ff5ec
  Saved registers:
   ebx at 0xbf3ff5ac, ebp at 0xbf3ff5e4, esi at 0xbf3ff5b0, edi at=20
0xbf3ff5b4,
   eip at 0xbf3ff5e8
(gdb) up
#2  0x4007035d in _svmf_interpreter (_env=3D0x8068e50) at=20
instructions_switch.c:15949
15949                 if (_svmf_enter_object_monitor (env, instance) !=3D=
=20
JNI_OK)
(gdb) info f
Stack level 2, frame at 0xbf3ffaac:
  eip =3D 0x4007035d in _svmf_interpreter (instructions_switch.c:15949);
     saved eip 0x40028c50
  called by frame at 0xbf3ffafc, caller of frame at 0xbf3ff5ec
  source language c.
  Arglist at 0xbf3ffaa4, args: _env=3D0x8068e50
  Locals at 0xbf3ffaa4, Previous frame's sp is 0xbf3ffaac
  Saved registers:
   ebx at 0xbf3ff5fc, ebp at 0xbf3ffaa4, esi at 0xbf3ff600, edi at=20
0xbf3ff604,
   eip at 0xbf3ffaa8
(gdb) info args
_env =3D (_svmt_JNIEnv *) 0x8068e50
(gdb) do
#1  0x4009a0a2 in _svmf_enter_object_monitor (env=3D0x8068e50,=20
instance=3D0x402a6014)
     at thread.c:863
863               _svmm_mutex_lock (owner->contention.owner.mutex);
(gdb) info args
env =3D (_svmt_JNIEnv *) 0x8068e50
instance =3D (_svmt_object_instance *) 0x402a6014
(gdb) info locals
_svmx_pmutex =3D (pthread_mutex_t *) 0x44
owner_id =3D 0
owner =3D (_svmt_JNIEnv *) 0x0
old_flag =3D 1094100508
notified =3D 0 '\0'
env =3D (_svmt_JNIEnv *) 0x8068e50
instance =3D (_svmt_object_instance *) 0x402a6014
vm =3D (_svmt_JavaVM *) 0x804cd48
old_lockword =3D 17
(gdb) do
#0  0x400bbe90 in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb) info locals
No symbol table info available.
(gdb) q