 |
» |
|
|
|
NAMEAries — emulate PA-RISC HP-UX applications on Itanium-based systems running HP-UX DESCRIPTIONAries is a dynamic binary translator which transparently emulates 32-bit and
64-bit PA-RISC HP-UX applications on Itanium-based HP-UX machines.
Aries is an acronym for
Automatic Recompilation and Integrated Environment Simulation.
Aries is transparent in the sense that:
The PA-RISC HP-UX application is not recompiled. The user does not explicitly invoke Aries.
The Itanium-based HP-UX operating system kernel recognizes a PA-RISC HP-UX
executable and invokes Aries to dynamically translate and execute the application. Aries consists of four shared libraries :
- /usr/lib/hpux32/pa_boot32.so
- /usr/lib/hpux32/aries32.so
- /usr/lib/hpux64/pa_boot64.so
- /usr/lib/hpux64/aries64.so
aries32.so
is the shared library that contains the Aries dynamic translator for 32-bit applications.
pa_boot32.so
contains code to load
aries32.so.
Likewise,
aries64.so
is the dynamic translator for 64-bit applications and
pa_boot64.so
loads
aries64.so.
Upon detecting a 32-bit PA-RISC HP-UX executable, the Itanium-based HP-UX
kernel invokes
pa_boot32.so,
which loads
aries32.so
into memory and sets it up to dynamically translate and execute the PA-RISC HP-UX executable.
Likewise,
aries64.so
is loaded for a 64-bit PA-RISC HP-UX executable. Aries consists of two major components:
Instruction Set Architecture (ISA) emulation engine Environment emulation engine
The ISA emulation engine is comprised of a fast interpreter and a dynamic
translator.
The interpreter emulates one instruction at a time, and when
a PA-RISC basic block has been executed a sufficient number of times,
the dynamic translator is called to translate the basic block.
The dynamic translator generates IA64 native code functionally equivalent
to the PA-RISC basic block.
Translated code is stored in translation code buffer.
Any further reference to the translated basic block does not need to be
interpreted or translated. The environment emulation engine is responsible for the PA-RISC
application's system calls, signal delivery, threads management, and so
forth.
Interactions among various Aries subsystems are controlled and facilitated by
the control system, which also keeps mapping between the PA-RISC application's
basic block addresses and the translated code basic blocks in the translated
code buffer. PA-RISC HP-UX GDB DEBUGGING SUPPORTAries supports debugging of PA-RISC HP-UX applications on Itanium-based HP-UX
systems, using PA-RISC HP-UX
gdb. On Itanium-based HP-UX systems,
/usr/ccs/bin
contains the PA-RISC
gdb32
and
gdb64
binaries.
A symbolic link named
/usr/ccs/bin/gdbpa
points to
/usr/ccs/bin/gdb32.
The Itanium-based HP-UX system's
gdb
debugger recognizes the binary being debugged as a PA-RISC binary and launches
/usr/ccs/bin/gdbpa
under Aries. Debugging PA-RISC Applications on Itanium-based SystemsUse the following steps to debug PA-RISC
applications on Itanium-based HP-UX systems using PA-RISC
gdb. - 1.
Set the environment variable
PA_DEBUG
to 1. - 2.
Set the environment variable
SHELL
to point to a PA-RISC shell, which should be present on the Itanium-based
machine on which debugging is being carried out.
You can obtain a PA-RISC shell
from a PA-RISC HP-UX machine from
/usr/bin. - 3.
Add
/usr/ccs/bin
to the
PATH
environment variable. - 4.
Run
gdb
as: $ gdb PA-RISC_binary - 5.
Note:
Make sure that user has write permission on
/tmp
directory and that there is space to create a temporary file of one page size
as obtained by
sysconf(_SC_PAGE_SIZE)
system call.
The rest of the debugging process is the same as that followed
on the PA-RISC HP-UX platform.
All commands of the
gdb
debugger are supported subject to limitations listed under
Limitations of PA-RISC GDB Support. Attaching PA-RISC GDB to PA-RISC process under AriesAn already running PA-RISC process can be debugged on Itanium-based systems
by attaching PA-RISC debugger gdb.
After attaching PA-RISC gdb to a PA-RISC
process under Aries all debugging operations remain same as that on a native
PA-RISC system. Attach
gdb
to already running PA-RISC process under Aries using the following steps :
- 1.
Perform the preparatory steps as described above for debugging PA-RISC
application under Aries using PA-RISC gdb. - 2.
$ gdb PA-RISC_binary PA-RISC_processID
After debugging is finished, perform the following steps.
- 1.
Unset the environment variable
PA_DEBUG. - 2.
Restore the original value of the
SHELL
environment variable.
Limitations of PA-RISC GDB SupportThe following are current limitations of PA-RISC
gdb
support.
- 1.
No support for debuggers other than PA-RISC HP-UX
gdb
for debugging an emulated PA-RISC application on an Itanium-based systems. - 2.
No support for old
gdb
versions (of HP-UX 10.20 and earlier).
However, debugging HP-UX 10.20
applications using a HP-UX 11.0 (and newer) PA-RISC
gdb
is supported. - 3.
PA-RISC
gdb
behaves differently for child processes created using
fork()
and
vfork()
system calls.
Since in Aries
vfork()
calls made by PA-RISC application are replaced by
fork()
calls, the exact behavior shown by PA-RISC
gdb
on a PA-RISC HP-UX platform is not shown by the PA-RISC
gdb
running under Aries on Itanium-based HP-UX platform in this case. - 4.
If the debugged process is blocking in a system call, any attempt to get to the
gdb
command prompt by pressing
^C
does not work.
The process has to be killed from outside. - 5.
Aries does not provide true emulation of MxN threads and thus does not
support debugging of PA-RISC applications that are linked with MxN pthreads
library. Note that the PA-RISC applications linked with MxN pthreads library
are emulated by Aries as traditional 1x1 threads and thus can only be
debugged under Aries as any other non-MxN multithreaded application.
See the section
Emulating MxN Threads
for more information.
Generation of PA-RISC HP-UX Compatible Core FileAries supports creation of PA-RISC core files on Itanium-based system,
when the emulated PA-RISC application dumps core. The size of the core file is limited by
ulimit()
and/or
setrlimit()
values.
See
ulimit(2)
and
setrlimit(2). The PA-RISC application core file generated by Aries will have the name as
core.PA-RISC_application_name. The PA-RISC HP-UX debugger is required to analyze core files generated
by Aries for PA-RISC applications.
For instance, the PA-RISC application core file generated by
Aries can be debugged using
/usr/ccs/bin/gdbpa
on Itanium-based system.
Alternately, the application's core file can be taken
to a PA-RISC machine and debugged using a PA-RISC debugger, though it is a very
tedious process and likely to be error-prone.
See section
Debugging Aries-Generated PA-RISC Core File on a Different Machine
for more information. After Aries has successfully written core file for PA-RISC application, it will
print the following message on
stderr:
ARIES32/64: Core file for PA32/64 application
saved to path/core.PA_application_name
If the emulated PA-RISC application results in a core file named just
core
or
core.pid,
it will be an Aries core dump and not that of the emulated PA-RISC application. An Aries-generated PA-RISC HP-UX compatible
core
file is recognized by the
file
command on PA-RISC and Itanium-based HP-UX machines.
See
file(1)
for more information. HP-UX 11i Version 3 NOTE:
- 1.
As per the default core file format in HP-UX 11i Version 3 Aries generates PA-RISC
application core file in new format.
In the new core file format large
utsname structure is written to core file.
See
uname(2)
for more details on large utsname structure.
You need to use latest version of tools like
gdb
which can work with new format core file. If you want Aries-generated core files to be in old format then use Aries
option
-core_format.
Refer to the section
ARIES RESOURCE CONFIGURATION FILE: PASSING OPTIONS TO ARIES. - 2.
If core file pattern and settings have been modified by
coreadm()
system call or by
init
settings - then Aries does not follow the pattern of writing the corefile to
core.
PA-RISC_application_name.
Instead Aries will write core file in the pattern as specified by
coreadm()
system call or by
init
settings.
Debugging Aries-Generated PA-RISC Core File on a Different MachineDebugging Aries-generated PA-RISC core file on different machine
(PA-RISC or Itanium-based system)
can be done only with PA-RISC gdb-3.0.01 or later. Use the following steps to debug an Aries-generated PA-RISC core
file on a machine other than the one on which the core file was generated.
- 1.
Transfer the core file and all the shared libraries used by the PA-RISC
application from the Itanium-based machine where the core dump file was
generated to the target machine. - 2.
Set the environment variable
GDB_SHLIB_PATH
to a colon-separated list of directory path names where the
transferred shared libraries reside. - 3.
Run
gdb
as: $ gdb PA_application PA_core_file
ARIES RESOURCE CONFIGURATION FILE: PASSING OPTIONS TO ARIESOptions to Aries are passed through a resource configuration file.
The Aries resource configuration file name is one of the following:
.ariesrc
for 32-bit Aries
(aries32.so) .aries64rc
for 64-bit Aries
(aries64.so)
Aries Resource Configuration File FormatThe Aries resource configuration file may contain multiple lines each of
the following format:
<full-path-of-PA-RISC-application1> <aries-options>
<full-path-of-PA-RISC-application2> <aries-options>
...
<full-path-of-PA-RISC-applicationn> <aries-options>
Exception:
Instead of the full path of the PA-RISC application, you can specify the
root
(/)
path.
If the root
(/)
path is specified, the following options are applied to all PA-RISC
applications being executed through Aries.
Specifying the root directory
(/)
in the first column acts as a wildcard.
All PA-RISC applications will execute
under Aries with the Aries options specified after the root
(/)
path in addition to Aries options present on lines matching individual
application names. The following rules specify the format of Aries resource configuration files.
- 1.
Separate the application path name and Aries options
by white spaces (for example, tab or space).
Multiple instances of white spaces are considered as single
white space. - 2.
Specify the application path name or the root
(/)
path starting from first column. - 3.
Specifying an invalid Aries option causes a fatal error and terminates the
emulated application. - 4.
An Aries resource configuration file may contain entries for multiple
applications.
In that case there should be separate lines beginning with each application
name. - 5.
A
#
character in first column comments out the whole line and options present
on the line are not processed by Aries.
Aries Resource Configuration File Search PathAries looks for resource configuration file in following locations:
User's home directory pointed to by the environment variable
HOME
The Aries search mechanism for resource configuration file is characterized by
the following:
- 1.
The Aries resource configuration file found in root directory
(/)
is the system-wide Aries resource configuration file.
Aries options
specified in this file will be applied to all invocations of PA-RISC HP-UX
applications on the machine. - 2.
The Aries resource configuration file found in the user's home directory
is that user's private Aries resource configuration file.
Aries options
specified in this file are applied to all the PA-RISC applications invoked
by the user. - 3.
Aries first processes the resource configuration file found in root directory
(/)
and then processes the file found in user's home directory. - 4.
Aries option processing is additive in nature.
If an Aries resource
configuration file is found in both paths, that is, in the root directory
(/)
and in a user's home directory, then Aries will give preference to options
present in the user's private Aries resource configuration file.
If the same Aries option is present in both the resource configuration files,
then the value of the option specified in the user's private resource
configuration will overwrite the value of option present in system-wide
resource configuration file. - 5.
If Aries finds the value of environment variable
HOME
to be
NULL,
or the path is not accessible, it does not process the Aries resource
configuration file in the user's home directory. - 6.
If Aries cannot find the resource configuration file either in the
root directory
(/)
or in the user's home directory, it uses the default values of options.
Useful Aries OptionsMost PA-RISC applications run as expected under Aries with default values
of options.
The following Aries options are useful for advanced users who
want to control Aries' resource management and/or tune Aries for their
PA-RISC applications. Note:
Aries options which are
On|Off
flags are turned
On
by presense of the option and are turned
off
by absence of the corresponding Aries option in the Aries resource
configuration file.
You do not need to specify the
On
or
Off
keywords in Aries resource configuration file to turn
ON or OFF a particular Aries option.
For example, specifying
-order
turns
On
the
-order
option in Aries.
Similarly, not specifying the
-order
option will turn
Off
the
-order
option in Aries. - -ap_heap_ssz size
Specifies the maximum size (in kbytes)
of memory area used for Aries private
heap.
This area is part of Aries heap
whose size is determined by Aries option
-heap_ssz.
This area is allocated from Aries heap
and is used for Aries'
malloc()
calls.
Remaining area of Aries heap is used for
allocating the new threads.
If the Aries errors
out of memory
or
malloc() failed
occur,
then you should increase this value. - -ccsz size
Specifies the maximum size (in kbytes)
of memory area used for Aries translated code
buffer.
Note:
It is recommended that you set this parameter value at default or maximum value.
A smaller value for this parameter will cause an increased frequency of Aries
translated code buffer flushes due to buffer full conditions.
This may result
in poor performance for PA-RISC application. In future Aries releases it may be possible to increase the maximum value of
this parameter greater than 16 MB. Though 64-bit Aries allows a maximum value of 16 MB for this parameter, it
actually reserves 64 MB.
The currently unused 48 MB space is
for larger translation code buffers in future. - -core_format version_specifier
Specifies the core file format for Aries-generated core files.
By default
Aries generates core file with large
utsname
structure.
Use this option if you want Aries to generate PA-RISC application
core file in format other than the default. The valid values of this parameter are - v1
(old core file format), v2
(new core file format) The default value of this parameter is
v2. - -corepid
Causes the process id (See
getpid(2))
to be appended to the core file name to which Aries writes PA-RISC
application's core file. If this option is turned
On,
the core file name will be
core.PA-RISC_application_name.PID .
The default value of this parameter is
Off. - -heap_ssz size
Specifies the maximum size of Aries heap (in kbytes).
The Aries heap is used to allocate internal Aries data structures and for
creating Aries threads for emulation of PA-RISC application threads. The Aries heap is divided into two parts - the first part is used as an Aries
private heap whose size is determined by the Aries parameter
-ap_heap_ssz.
Remaining area from the Aries heap is used to allocate memory for new threads.
The values above are shown with the default values of kernel tunable parameters
pa_maxssiz_32bit
and
pa_maxssiz_64bit
for 32-bit Aries and 64-bit Aries respectively. With increased values of the kernel tunable parameters
pa_maxssiz_32bit
and
pa_maxssiz_64bit
for 32-bit Aries and 64-bit Aries respectively, the maximum value of
the Aries heap is computed as follows.
32-bit Aries
heap_ssz = pa_maxssiz_32bit - ssz - ccsz - 10 MB 64-bit Aries
heap_ssz = pa_maxssiz_64bit - ssz - ccsz - 33 MB
- -issz size
Specifies the size of initial allocated stack (in kbytes)
for PA-RISC application.
At startup time, Aries computes the minimum value of
-issz
by adding the sizes of argument strings, environment strings, and
keybits structure.
If the computed value is greater than 64 Kb, Aries sets the minimum value of
-issz
to the computed value. - -noasync_chk
Causes Aries to not generate asynchronous event check stub in translated
code.
This option can be used only with nonmultithreaded applications.
This option can provide better performance for CPU intensive workloads. The default value of this parameter is
Off. - -nocompat_core
Causes Aries to generate core file with OS field with release version of the
HP-UX on native Itanium-based systems.
Such core file may not work with
gdb
from older HP-UX platform. The default value of this parameter is
Off. - -noopt_ldcw
Causes Aries to not optimize translation for PA-RISC opcode LDCW and LDCD.
Use this option only if multithreaded does not work correctly under Aries.
Using this option causes slowdown of the order of 3x-4x. The default value of this parameter is
Off. - -nosched
Causes Aries to not optimize and schedule the translated code.
This option
is useful only to triage problems when an application fails running in
translated code.
Using this option can slowdown performance by about 20%. The default value of this parameter is
Off. - -notrans
Instructs Aries not to translate any PA-RISC basic blocks.
Instead, all the basic blocks will be emulated through the Aries interpreter.
This option causes severe performance degradation.
This option is useful only to triage problems if a PA-RISC application
fails while running with Aries dynamic translator. The default value of this parameter is
Off. - -nounsafetrans
Do not dynamically translate the self modifying code.
This option is useful
only to triage problems encountered in running PA-RISC JVM under Aries.
This option causes about 2x performance slowdown for Java based applications. The default value of this parameter is
Off. - -order
Specifies that the PA-RISC application expects strong memory ordering.
Use this option only when a PA-RISC application expecting strong memory
ordering fails under Aries.
Such an application would be one which does not use memory ordering
semantics like
,O
completer in
load/store
instructions and still expects strong memory ordering.
Using this option causes 3x-4x performance slowdown. The default value of this parameter is
Off. - -osinc size
Specifies the chunk size (in kbytes) for incremental memory allocation
in Aries for PA-RISC application stack, Aries heap, and so on.
The maximum and minimum values of this parameter are not checked in Aries.
The maximum value of this parameter should be the least of following:
ssz,
ccsz,
heap_ssz
values, and 5 MB.
The minimum value of this parameter should be the default page size, that is, 4 KB. Note:
Specifying a low value for this parameter may cause slow performance
for PA-RISC applications due to too many small mmap'd regions.
This may lead to performance slowdown of the whole system.
This is because operating system allocates one protection ID for each
memory mapped region.
Too many protection IDs may lead to increased DTLB misses. - -pa_os_cpu
Affects the emulation of the
uname()
and
sysconf()
system calls to return information specific to the PA-RISC processor and HP-UX
release version. Most PA-RISC applications run as expected under Aries without this option
being set.
Use this option if and only if PA-RISC application expects the return
values of
uname()
and
sysconf()
system calls, to be specific to the values that would have been obtained if
the application was running on PA-RISC HP-UX system. The default value of this parameter is
Off. - -ssz size
Specifies the maximum stack size (in kbytes) for PA-RISC application.
The values above are shown with the default values of
the kernel tunable parameters
pa_maxssiz_32bit
and
pa_maxssiz_64bit
for 32-bit Aries and 64-bit Aries respectively. With increased values of the kernel tunable parameters
pa_maxssiz_32bit
and
pa_maxssiz_64bit,
the maximum value of the
-ssz
Aries parameter will be the same as maximum value of kernel tunable parameters
maxssiz
and
maxssiz_64bit
for 32-bit and 64-bit processes respectively. Aries sets the size of the PA-RISC application stack by the size returned by
getrlimit (RLIMIT_STACK, ...)
system call or the value inherited from parent process.
Use this option to
override the stack size for PA-RISC application. - -ts n
Specifies the Aries translation threshold
n,
where
n
is an integer value.
This option specifies the number of times Aries
interprets a basic block before considering it as a candidate for
dynamic translation.
This option can be used to tune a PA-RISC application's performance
under Aries. The default value of this parameter is
16.
Example: Aries Resource Configuration FileTo execute a 32-bit PA-RISC application
hello_world
through Aries using 32 MB of PA-RISC emulated stack,
you can place a
.ariesrc
file containing the following line in user's home directory
or in the root
(/)
directory.
/user/foo/hello_world -ssz 32768 Alternatively, if the following line is specified, then the stack size of
32 MB will be applied to all 32-bit PA-RISC applications invoked by the user
or by all users depending on whether the Aries resource configuration is
located in user's home directory or root directory.
Sample Aries resource configuration files are shown below.
You can modify these files to suit your application executable
paths and required Aries options. An example of a user's private Aries resource configuration file located
in that user's home directory follows.
/home/user1/bin/app1 -ssz 24576 -heap_ssz 32768
/home/user1/app2 -core_format v1 -corepid
/home/user1/dbg/app3 -order
/home/user1/dll/bin/app4 -osinc 256 -issz 1024 -ts 10
/home/user1/app5 -pa_os_cpu
/home/user1/bin/app6 -ts 8 -ssz 16536 -core_format v1 -heap_ssz 24576 -osinc 1024
/usr/bin/X11/xterm -ssz 24576 -heap_ssz 32768 -ap_heap_ssz 10240
/usr/local/bin/vim -osinc 256 -issz 3072 An example of a system wide global Aries resource configuration file
located in the root
(/)
directory follows.
/usr/bin/app1 -osinc 256 -issz 1024 -ts 10
/usr/local/bin/app2 -core_format v1 -corepid
/opt/App/bin/app3 -order
/usr/local/lib/app/bin/x -ssz 24576 -heap_ssz 32768 -ap_heap_ssz 5120
/home/user2/app5 -pa_os_cpu
/home/user4/bin/app6 -ts 8 -ssz 16536 -corefile_v1 -heap_ssz 24576 -osinc 1024 ARIES MEMORY MANAGEMENTAries Managed Area (AMA)Aries consumes a small amount of memory towards the end of a PA-RISC
application's private data segment.
This area is called Aries Managed
Area (AMA).
When an Itanium-based HP-UX operating system launches Aries to
emulate PA-RISC application, it reserves AMA exclusively for Aries use.
The size of the AMA is decided by following kernel tunable parameters:
pa_maxssiz_32bit
for 32-bit Aries pa_maxssiz_64bit
for 64-bit Aries
See
pa_maxssiz(5)
for more details. The Itanium-based HP-UX operating system passes a pointer
load_info
to a structure of type
load_info_t
defined in
/usr/include/crt0.h,
to Aries.
The start of AMA is marked by
load_info->li_priv_mmf_start
and the end of AMA is marked by
load_info->li_bstore_start.
Aries uses AMA to store following data:
- 1.
Aries's initialized data, uninitialized data (BSS) and thread local
storage (TLS) - 2.
Aries heap for
malloc()
calls used by Aries code and for creating Aries
threads for emulation of PA-RISC application's threads - 3.
PA-RISC application's stack - 4.
Translation code buffer (code cache region) - 5.
Aries's private data structures - 6.
Memory area used by Aries dynamic translator as heap
The whole of AMA space is not allocated at once.
Aries allocates memory
from AMA dynamically.
Due to AMA, a PA-RISC application running under Aries will have
larger memory footprint (also called resident memory) compared to PA-RISC
native system.
The increase in resident memory size is not equal to the size of
AMA.
Instead, the amount of increase in resident memory size
is decided by how much memory actually gets allocated from AMA. Relation between pa_maxssiz_32|64bit, and Aries Parameters32-bit AriesAt process startup time, Aries reserves space for PA-RISC application stack in
AMA.
The maximum size of PA-RISC application stack is computed as follows:
max_pa_stack_size = least of following two factors:
- 1.
ti_current
value in structure of type
tuneinfo2_t
defined in
/usr/include/sys/dyntune.h
by making system call
tuneinfo2
with parameter
maxssiz. - 2.
A value fixed by Aries based on current value of kernel tunable parameter
pa_maxssiz_32bit
as follows: if (pa_maxssiz_32bit < 128 MB)
max_pa_stack_size = pa_maxssiz_32bit - 48 MB
else
max_pa_stack_size = pa_maxssiz_32bit - 64 MB
AMA is divided into different memory regions as follows:
pa_maxssiz_32bit = max_pa_stack_size +
PA-RISC Application stack size (ssz) +
Aries heap size (heap_ssz) +
Aries translation code buffer size (ccsz) +
5 MB (Aries Dynamic Translator heap) +
5 MB (Aries data etc)
Examples - 1.
If a 32-bit PA-RISC application requires a 128 MB stack size, set kernel
tunable parameter
pa_maxssiz_32bit
to 128 MB (ssz) + 22 MB (heap_ssz) + 16 MB (ccsz) + 10 MB = 176 MB - 2.
If a 32-bit PA-RISC application requires a maximum possible stack size,
set the kernel tunable parameter
pa_maxssiz_32bit
to 383 MB (ssz) + 22 MB (heap_ssz) + 16 MB (ccsz) + 10 MB = 431 MB - 3.
If a 32-bit PA-RISC application requires a 128 MB of Aries heap, assuming
32 MB of application stack, set the kernel tunable parameter
pa_maxssiz_32bit
to 32 MB (ssz) + 128 MB (heap_ssz) + 16 MB (ccsz) + 10 MB = 186 MB
64-bit AriesAt process startup time Aries reserves space for the PA-RISC application
stack in AMA.
Maximum size of PA-RISC application stack is computed as follows:
max_pa_stack_size = least of following two factors:
- 1.
ti_current
value in structure of type
tuneinfo2_t
defined in
/usr/include/sys/dyntune.h
by making system call
tuneinfo2
with parameter
maxssiz_64bit. - 2.
max_pa_stack_size = pa_maxssiz_64bit - 224 MB
AMA is divided into different memory regions as follows:
pa_maxssiz_64bit = max_pa_stack_size +
PA-RISC Application stack size (ssz) +
Aries heap size (heap_ssz) +
Aries translation code buffer size (ccsz) +
8 MB (Aries Dynamic Translator heap) +
25 MB (Aries data etc).
Examples: - 1.
If a 64-bit PA-RISC application requires a 512 MB stack size, set kernel
tunable parameter
pa_maxssiz_64bit
to 512 MB (ssz) + 128 MB (heap_ssz) + 64 MB (ccsz) + 33 MB = 737 MB - 2.
If a 64-bit PA-RISC application requires the maximum possible stack size,
set kernel tunable parameter
pa_maxssiz_64bit
to 1024 MB (ssz) + 128 MB (heap_ssz) + 64 MB (ccsz) + 33 MB=1249 MB - 3.
If a 64-bit PA-RISC application requires a 512 MB of Aries heap, assuming
256 MB of application stack, set kernel tunable parameter
pa_maxssiz_64bit
to 256 MB (ssz) + 512 MB (heap_ssz) + 64 MB (ccsz) + 33 MB = 865 MB
PA-RISC APPLICATION THREADS EMULATION UNDER ARIESCalculating the Required Size of the Aries HeapTo emulate PA-RISC application's threads, Aries needs to create its own
native threads whenever a PA-RISC application creates new threads.
To create new threads, Aries needs to allocate memory to accommodate
thread specific data, thread stack, and thread backing store area for the
new thread.
Memory requirement for thread creation in Aries is as follows:
For 32-bit Aries:
215 KBytes For 64-bit Aries:
280 KBytes
Apart from the memory required to allocate new threads, Aries needs some
memory for its internal dynamic data structures allocation.
The size of the
Aries private heap is determined by the Aries parameter
-heap_ssz.
Aries divides the heap area into two parts — the first part is used for the
Aries private heap and the second part is used for allocation of new threads.
Thus the required amount of space for the Aries heap is calculated as follows:
Required Aries Heap Size =
-ap_heap_ssz KB + (Number of PA-RISC application threads) *
(Memory required to allocate one Aries thread, in KB)
Maximum Number of Threads that Aries Can CreateA PA-RISC application can create a maximum of 86 threads under 32-bit Aries
with the default value of the kernel tunable parameter
pa_maxssiz_32bit
and default values of the 32-bit Aries parameters.
The same application can
create a maximum of 439 threads under 64-bit Aries with the default value of
the kernel tunable parameter
pa_maxssiz_64bit
and default values of 64-bit Aries parameters. Check to see that the value of your kernel tunable parameter
max_thread_proc
is not less than the required number of threads that your PA-RISC
application needs to create. If your PA-RISC application needs to create a larger number of threads
than the maximum number of threads that can be created with default
values of Aries parameters and the kernel tunable parameter
pa_maxssiz_32|64bit,
then increase the Aries heap size by specifying the
-heap_ssz
option in the Aries resource configuration file. Note:
The amount of free memory available in AMA on account of reducing a
PA-RISC application's stack size (Aries option
-ssz)
cannot be automatically used by Aries to allocate more space to the
Aries heap.
To change the Aries heap size, you must set the Aries option
-heap_ssz
in the Aries resource configuration file. Emulating MxN ThreadsAries supports PA-RISC applications which are linked with the MxN pthreads
library.
With this release of HP-UX, the PA-RISC MxN pthreads library is
delivered on Itanium-based system. A future release of Aries may have support for true emulation of MxN pthreads.
Until that time, Aries supports emulation of PA-RISC HP-UX applications
linked with MxN pthreads library in traditional 1x1 mode.
Aries achieves this by internally setting the environment variable
PTHREAD_COMPAT_MODE
to
1. EMULATING PA-RISC APPLICATION STACK UNDER ARIESThe stack allocated by the Itanium-based HP-UX kernel is used by Aries
as its own native stack.
Aries allocates the stack for PA-RISC applications from AMA.
Most PA-RISC applications run as expected with default stack size
set by Aries.
However, if your PA-RISC application fails with core dump, with the
following error message,
then you should increase the PA-RISC application stack size by using
Aries option
-ssz
in the Aries resource configuration file.
ARIES32|64 Limitation/Error
PID xxxxx received SIGSEGV for stack growth failure
Possible causes - insufficient memory or swap space,
or stack size exceeded pa_maxssiz_32|64bit
Aries does not support applications which are nearly or completely
maxed out on their data segment address space usage.
This is because
Aries consumes small amount of virtual memory address space of
application
Terminating emulation
How Aries Sets PA-RISC Application Stack SizeAt process startup time, Aries sets the size of the PA-RISC application
stack based on following criteria:
- 1.
Aries first checks if Aries option
-ssz
is present in the Aries resource configuration file.
If so, it sets the value of the PA-RISC application stack with the value of
-ssz. - 2.
If the Aries option
-ssz
is not present, Aries checks if the stack size limits are specified by
the parent process.
If specified, Aries sets the size of the PA-RISC application stack as
specified by parent process.
The parent process can modify the stack size limits by the system
call
setrlimit (RLIMIT_STACK, ...). - 3.
If the Aries option
-ssz
is not present and the parent process has not specified the stack size limits,
Aries sets the value of the PA-RISC application stack size to the
value obtained by the system call
getrlimit (RLIMIT_STACK, ...).
If the application was invoked from a shell, this value will be same as
the value set by the user in the shell as
ulimit -s. For details on the maximum possible stack size that Aries can allocate,
see the section
Relation between pa_maxssiz_32|64bit, and Aries Parameters. Note:
Stack sizes can be inherited among an Itanium-based system's
native processes (32-bit and 64-bit) and emulated PA-RISC processes (32-bit
and 64-bit).
This is subject to the limitation on available stack space.
For example, a 64-bit process can set a stack size which is not possible
to allocate in 32-bit process's address space.
In that case the 32-bit process will use maximum stack space.
ARIES PERFORMANCEFor the purpose of performance comparison we assume similarly priced and
fully configured PA-RISC and Itanium2-based systems.
Because of different
processor caches, memory slots, bus speeds it is not possible to find
PA-RISC and Itanium-2-based identical systems as regards to machine
resources. Relative performance of PA-RISC applications under Aries running on a
Itanium-2-based system running at 1600 MHz is shown in table below. Performance numbers shown in above table are only indicative.
The actual
performance of your application may vary depending on application
execution profile.
It is recommended that you benchmark performance of
your applications under Aries on Itanium-2-based systems before actual
deployment. Aries performance can be characterized by following points:
- 1.
General applications are those which have average mix of I/O intensive,
memory intensive and system intensive operations.
Such applications run
with good performance under Aries. - 2.
Integer intensive applications are those which spend significant time in
algorithmic computations.
Such applications run with good performance under
Aries. - 3.
Floating point intensive applications are generally scientific simulation,
modeling applications.
Such applications suffer performance under Aries due
to architectural differences between PA-RISC and Itanium-2 processor
feature and resources for floating point operations. - 4.
Unless your Java based application uses JNI code it is recommended that you
run your application with Itanium-2 native JVM.
Depending on execution
profile performance of Java based applications varies quite a lot under Aries. - 5.
Aries performance for multithreaded PA-RISC applications is poorer than
the nonthreaded counterpart of the same application.
Multithreaded
applications cause threads synchronization overhead in Aries.
Aries can
suspend a thread only when it reaches a suspension safe point in Aries so
as to provide correct emulated context to application. - 6.
PA-RISC applications which make use of performance libraries like
HP mlib
are not good candidates to run under Aries.
Performance library (for example,
HP mlib)
kernels are hand-coded in assembly and are tuned to the cache behavior and
instruction resources as to achieve closer to theoretical machine peak rate.
It is not possible for a software emulator like Aries to emulate this detailed
behavior of the application for maximum hardware resource utilization. - 7.
PA-RISC applications that make extensive use of
OpenGL
experience slow
performance.
This is because the
ogld
daemon process on an Itanium-based machine is a native process, and an
emulated application cannot send its graphics output to a native graphics
card by directly communicating with the
ogld
daemon process.
Such PA-RISC applications send their graphics data to the Itanium-based
machine's graphics card through a virtual memory driver (VMD) which
is emulated under Aries.
This process of displaying the graphics data is slow.
Instead, such applications should make use of
OpenGL display lists
by using GLX protocol mode.
This process of displaying graphics data with
OpenGL
can be significantly faster than the virtual memory driver route.
ARIES SUPPORTED APPLICATIONSAries supports emulation of all PA-RISC HP-UX applications.
This means
all the HP-UX Inter-Process Communication mechanisms such as semaphores,
shared memory, sockets, and so forth, are supported.
All inter-process communications between an emulated PA-RISC application
and a native-running Itanium-based application is supported.
The signal/exception behavior of a PA-RISC HP-UX application is supported
under Aries.
There is only a very small subset of the PA-RISC application domain
that is not supported under Aries.
To ascertain whether a given application will run correctly under
Aries or not, determine if the application falls into one of the Aries
limitations described in the section
ARIES LIMITATIONS. ARIES LIMITATIONSAries supports emulation of all PA-RISC HP-UX applications, with the following
limitations/exceptions:
- 1.
Aries does not support PA-RISC applications that load Itanium-based shared
libraries.
In other words, mixing PA-RISC binaries with Itanium-based shared
libraries is not supported.
Aries is meant only for pure PA-RISC applications, such as binaries that
are either statically or dynamically linked with PA-RISC libraries only.
However, any sort of inter-process communication between a native
Itanium-based application and an emulated PA-RISC application is supported. - 2.
The version of Aries at this release
supports PA-RISC HP-UX applications that run on
HP-UX 11i Version 3
and below.
Aries does not support applications compiled on HP-UX version 8.x
or earlier.
However such applications run as expected if they run on a
contemporary version of HP-UX (for example,
HP-UX 11i Version 3
and earlier). - 3.
Aries does not support privileged PA-RISC instructions.
Hence, device drivers and loadable kernel modules are not supported. - 4.
Aries does not guarantee correct emulation of PA-RISC applications which make
assumptions about "time taken to execute certain pieces of application code
and/or system calls".
Such applications are theoretically un-synchronized applications, and
hence, need to be corrected with proper synchronization techniques using
mutex locks, semaphores, and so forth.
Such un-synchronized applications are found to be very rare in practice. - 5.
Aries does not support applications that use the
ptrace()
or
profil()
system calls.
However, Aries supports debugging of emulated application using PA-RISC
gdb.
See section
PA-RISC HP-UX GDB DEBUGGING SUPPORT
for additional information.
This limitation might affect debugger applications, which are normally not
portable anyway. - 6.
Aries consumes a small amount of an application's virtual memory address space.
Therefore Aries does not support applications that are nearly or completely
maxed out on their virtual address space usage.
Such applications, in practice, have been found to be extremely rare. - 7.
Aries supports both
fork()
and
vfork()
system calls.
However, Aries does not support applications that rely on differences between
fork()
and
vfork().
However, most applications that use the
vfork()
system call do use it with a purpose which is well known to the programmer.
It is an extremely rare condition that a standard application would have
any such reliance on the differences between
fork()
and
vfork()
calls.
See
vfork(2)
and
fork(2)
for details. - 8.
When an emulated application makes any system call that returns the
processor-related information, then under emulation, Aries returns information
pertinent to a PA-RISC 2.0 processor, even though the emulated application runs
on an Itanium-based machine.
For instance, a call made to
sysconf(2),
with
_SC_CPU_VERSION,
will return
CPU_PA_RISC2_0.
This is an Aries policy, that an emulated application sees a complete PA-RISC
environment on Itanium-based system.
If the application requires that it be able to determine that it is
running on an Itanium-based machine, one method is for the application
to use the
system()
call and the Itanium-based native command
getconf
to get the required fields.
See
system(3S),
getconf(1),
and
sysconf(2)
for more information.
AUTHORAries was developed by HP. SEE ALSOfile(1),
gdb(1),
getconf(1),
init(1M),
coreadm(2)
execve(2),
fork(2),
getrlimit(2),
setrlimit(2),
signal(2),
sysconf(2),
ulimit(2),
uname(2),
vfork(2),
system(3S),
core(4),
pa_maxssiz(5).
|
Printable version
