jvm hangs on itanium

[Satya_6]

Hi,

I have got a JNI application, but it hangs on Jvm initialisation on Itanium processor system.

The problem looks to be in the pthead, in the debugger I can see that it just waits in pthread_cond_wait func.

I am linking the following libraries in the given order.

-lc -lGLU -lGL -lMrm -lXm -lXt -lXext -lXmu -lX11 -lm -lpthread -lhpi -ljvm

If I don't link the libc library the application gets kiled with SIGABRT and if I link it, it comes in way of pthread library,

anu help would be greatly appreciated.

TIA
satya

[Mike Stroyan]

You should not be linking -lc before -lpthread. It forces the use of stub pthread routines from libc. Leave off -lc and link with cc or aCC so libc is implicitly linked at the end of the link list.
Then start working on why you get a SIGABRT. ;-)
Do you have a stack trace for the SIGABRT?
Did dld.so complain about missing symbols?

[Satya_6]

Hi,

This is the trace I get.

#0 0x2000000078895cb0:0 in kill+0x30 () from /usr/lib/hpux32/libc.so.1
#1 0x2000000078793f00:0 in raise+0x40 () from /usr/lib/hpux32/libc.so.1
#2 0x2000000078858550:0 in abort+0x210 () from /usr/lib/hpux32/libc.so.1
#3 0x200000007894a450:0 in std::terminate+0x50 ()
from /usr/lib/hpux32/libCsup.so.1
#4 0x20000000789436d0:0 in __cxa_throw+0x130 ()
from /usr/lib/hpux32/libCsup.so.1
#5 0x2000000078ae22e0:0 in std::ios_base::setf+0xe0 ()
from /usr/lib/hpux32/libstd_v2.so.1
#6 0x2000000078adf960:0 in std::ios_base::Init::Init+0x1c70 ()
from /usr/lib/hpux32/libstd_v2.so.1
#7 0x6f5cb50:0 in NamedNodeMapImpl::cloneContent+0x5d0 ()

TIA
satya

[Mike Stroyan · Accepted solution]

The stack trace shows that your program was linked with libstd_v2.so, meaning that it was linked by aCC with the default -AA mode. The java libjvm.so is linked with libstd.so, meaning that it was linked with aCC with the -AP option. The aCC -AA and aCC -AP modes can't be mixed in one program. To use java JNI you will need to compile your C++ code with aCC -AP and link your program with aCC -AP. That means that the iostream API will use the unnamed namespace instead of the std namespace.

[Satya_6]

Hi Mike,

That solved the problem. Thank you very much.

I am facing a problem with the executable created on HP-UX B.11.11 (9000/785) PA_RISC2.0 The executable runs very slow on a m/c with itanium processor (HP-UX B.11.22). It is almost 3 to 4 times slower when run on the itanium m/c.

(Actually I am compiling the files using /opt/ansic/bin/cc and creating static .a libs and linking using aCC (version HP ANSI C++ B3910B A.03.30). I am compiling some xml parser stuff in aCC)

I am using the following compiler option.

to compile:
-Aa -Ae +Z -O +Oprocelim +Ofastaccess +Oaggressive

to link: (for aCC)
+eh +Z -z

I am linking the following libraries

-lGL -lGLU -lXm -lXt -lXext -lXmu -lX11 -lm
(Removed the -lc after your suggestion here also)

This would help in having only one executable for both PA-RISC2.0 and itanium m/c.


TIA
satya

[Mike Stroyan]

You won't get good performance out of a PA-RISC executable on and Itanium system. Such programs are run by the exec call wrapping them with aries library. Aries interprets PA-RISC instructions. It eventually translates frequently executed instructions into native Itanium code equivalents. That won't perform as well as code compiled for Itanium.

The java jvm is a wild thing to run under aries. The hotspot jvm is interpreting java bytecode. It eventually translates hot routines to PA-RISC instructions. If those instructions are executed often enough they may
be translated to Itanium instructions. The layers of interpretation and translation get rather dizzying to contemplate.

If your program actually spends much of its time calling OpenGL, then you definitely would want to make effective use of display lists. If you can put together a big image as a tree of display lists, then one glCallList function could hand off all that work to the X server. The X server, (and its ogld helper process), are native IPF code on an Itanium based system. They can run at full speed.