Am I running in 32-bit emulation????

[Peter Kovacs 1.0rc]

Hi

I am logged in as root:

# ulimit -sH
8192

# kctune tunable maxssiz
Tunable Value Expression Changes
maxssiz 8388608 Default Immed

# kctune tunable maxssiz_64bit
Tunable Value Expression Changes
maxssiz_64bit 268435456 Default Immed

This leads me to think that the system (or my shell?) is running in 32-bit emulation. (I instinctively would expect root to have a stack size hard limit equal to the system's configured maximum.) Also, my application runs 2-4 times slower than I had expected, for which a plausible explanation would be that it runs in emulation mode.

uname says this:

# uname -a
HP-UX apollo B.11.23 U ia64 1874023332 unlimited-user license

How can I find out if a process is running in 32-bit emulation mode?

If my assumption is wrong and hard limits for root are not necessarily equal to the system's configured maximums, how can change the hard limits for root?

Thanks a lot in advance.

Peter

[RAC_1]

It is. file `which ksh/sh` (depending upon what shell are you running.

[Robert-Jan Goossens_1]

Hi Peter,

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000082168856

Title: HP-UX: Shells and resource limits
Document ID: HPUXNEWSI316A6
Last Modified Date: 1/31/06

Regards,
Robert-Jan

[Dennis Handly]

What do you think 32-bit emulation is?
Did you mean PA emulation with Aries?

Also, if you are worried about performance, changing maxdsiz, maxssiz won't make any difference. You must recompile the application and libs natively.

[Peter Kovacs 1.0rc]

Dennis,
I thought 32-bit emulation is an additional layer to "emulate" i686 instructions (or x86_32 instructions, if you wish) on top of Itanium processors. (Since, as far as I remember, Itanium has been designed from the very beginning to be 64-bit, the notation IA32 is probably corresponding to the i*86 i.e. x86_32 CPU family.) But I may be, of course, wrong.

Based on the document referenced in Robert-Jan's reply, the ulimit issue is probably moot: all shells are 32-bit, so they will use 32-bit kernel parameters for hard limits (or something like that).

Here is the entire story:

I installed java1.5 from jdk15_15005_ia.depot, which, to all appearances, is an Itanium based Java package. What I get (among others) are three "java" files:
a) /opt/java1.5/bin/java
b) /opt/java1.5/bin/IA64N/java
c) /opt/java1.5/bin/IA64W/java

a) is PA-RISC2.0 executable dynamically linked -not stripped.
b) is ELF-32 executable object file - IA64
c) is ELF-64 executable object file - IA64

Based on my experience with other platforms (Solaris, Linux) supporting multiple instructions sets, I would expect file (a) to be a script, which decides (based on environment variables or other kinds of environment specific system properties) which flavour of the run-time to start. Translating this to my specific case: I would expect file (a) to decide which one to run: file (b) or file (c). However, what I see is a PA-RISC executable, which I am afraid is running in emulated mode.

This problem increasingly appearing an application specific issue, I start to feel that I am in the wrong category here. But at the time I posted my question I thought this is a more general HP-UX issue. Still, if, incidentally, you happen to have any clues I would highly appreciate them, because I could not find nothing useful in this regard in the Java-related HP docs thus far.

[Peter Kovacs 1.0rc]

With a ps -ef, I can now see that the 32-bit executable (image (b)) is running. (Despite file (a) being an executable, it appears to be a mere dispatcher.)

Starting java (file (a)) with the '-d64' option results in file (c) (64-bit) actually running. The doc for '-d64' says:

"Runs Java in 64-bit mode. In HP SDK 1.4, interpreter and compiler -Xint, -Xmixed, and -Xcomp modes are supported."

Hmm, after all, should IA32 mean the same instruction set with a different memory address size? Is there no emulation involved here?

Thanks for your patience
Peter

[Dennis Handly · Accepted solution]

>I thought 32-bit emulation is an additional layer to "emulate" i686 instructions (or x86_32 instructions)

While this may be true, on HP-UX there is no x86 stuff. Any emulation is for PA-RISC.

>I would expect file (a) to be a script

It could be a script or a PA executable. As long as its performance isn't critical.

>should IA32 mean the same instruction set with a different memory address size?

No IA32 means x86.

HP-UX runs on PA and IPF. Both 32 and 64 bit data models.
IPF hardware only supports 64 bit instructions/addresses. It is compiler magic that allows 32 bit data model applications to run.

If you use file(1) you see:
ELF-32 executable object file - IA64
ELF-64 executable object file - IA64

[Carsten Krege]

Perhaps the Intel Software Developer's Manual helps you to understand this. http://www.intel.com/design/itanium/manuals/245318.htm

On HPUX we use "swizzling" (search above PDF for this).

"The pointer â swizzlingâ model performs address computations with the addp4, and shladdp4
instructions. These instructions generate a 32-bit address within the 64-bit virtual address space ..."

The top two bits (bits 31 and 30) of the 32-bit pointer are copied to the top three bits (bits 62 and 61) of the 64-bit pointer, with the remaining 30 bits zeroed out.

YOu can easily find what sort of executable you have on a IA64 HPUX system:

hello_ia64_32: ELF-32 executable object file - IA64
hello_ia64_64: ELF-64 executable object file - IA64
hello_pa_32: PA-RISC2.0 shared executable dynamically linked -not stripped
hello_pa_64: ELF-64 executable object file - PA-RISC 2.0 (LP64)

Carsten

[Peter Kovacs 1.0rc]

Dennis,
Thank you for the clarification. I confused 32-bit processor architecture with 32-bit virtual addressing.

Being basically a Java/database developer, I am not exposed to the manifold intricacies that C programmers have to deal with in terms of pointer sizes and data models in general. No wonder I get easily confused. (I am still not sure why any C program designed for a 32-bit architecture cannot be simply "cross-compiled" for a pure 64-bit architecture. But I recognize that helping me understand this would be quite a digression from this topic.)

In the meantime, I did more tests with my application and it appears that the performance problem is mostly due to the database used by the application. Portions of the application which do not interact with the database are more or less in line with my initial expectations (which had been fairly vague anyway).

Thanks again for your help.

Peter

[Peter Kovacs 1.0rc]

My question has been answered by clarifying some misunderstandings on my end.

[rick jones]

Since you mentioned performance, if you are experiencing performance issues, some things to consider examining:

*) profiles - http://www.hp.com/go/caliper and/or HP Jmeter.

*) If doing networking, check netstat and/or lanadmin statistics

*) system call traces via tusc, or counts via glance - if you see lots of sched_yield() and ksleep/kwakeup you may have a lock contention issue in your application