NSJ 11 User Guide
Part Number: 10-180400-13
Published: August 2023
Edition: 1
NSJ 11 User Guide
Part Number: 10-180400-13
Published: August 2023
Edition: 1
© Copyright 2020–2023 Hewlett Packard Enterprise Development LP
Notices
The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and
services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as
constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained
herein.
Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or copying. Consistent with FAR
12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are
licensed to the U.S. Government under vendor's standard commercial license.
Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard Enterprise has no control over and is
not responsible for information outside the Hewlett Packard Enterprise website.
Acknowledgments
Ampere®, Altra®, and the A®, and Ampere® logos are registered trademarks or trademarks of Ampere Computing.
Adobe, the Adobe logo, Acrobat, and the Adobe PDF logo are either registered trademarks or trademarks of Adobe in the United States
and/or other countries.
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the U.S. and/or elsewhere.
DLTtape logo and SDLTtape logo are trademarks of Quantum Corporation in the U.S. and other countries.
Java is a registered trademark of Oracle and/or its affiliates.
OpenJDK Trademark Notice
https://openjdk.org/legal/openjdk-trademark-notice.html
Warranty
OSF MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THE OSF MATERIAL PROVIDED HEREIN, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
OSF shall not be liable for errors contained herein or for incidental consequential damages in connection with the furnishing, performance, or
use of this material.
© 1990, 1991, 1992, 1993 Open Software Foundation, Inc. This documentation and the software to which it relates are derived in part from
materials supplied by the following:
© 1987, 1988, 1989 Carnegie-Mellon University. © 1989, 1990, 1991 Digital Equipment Corporation. © 1985, 1988, 1989, 1990 Encore
Computer Corporation. © 1988 Free Software Foundation, Inc. © 1987, 1988, 1989, 1990, 1991 Hewlett-Packard Enterprise Company. ©
1985, 1987, 1988, 1989, 1990, 1991, 1992 International Business Machines Corporation. © 1988, 1989 Massachusetts Institute of
Technology. © 1988, 1989, 1990 Mentat Inc. © 1988 Microsoft Corporation. © 1987, 1988, 1989, 1990, 1991, 1992 SecureWare, Inc. ©
1990, 1991 Siemens Nixdorf Informations system AG. © 1986, 1989, 1996, 1997 Sun Microsystems, Inc. © 1989, 1990, 1991 Transarc
Corporation.
This software and documentation are based in part on the Fourth Berkeley Software Distribution under license from The Regents of the
University of California. OSF acknowledges the following individuals and institutions for their role in its development: Kenneth C.R.C. Arnold,
Gregory S. Couch, Conrad C. Huang, Ed James, Symmetric Computer Systems, Robert Elz. © 1980, 1981, 1982, 1983, 1985, 1986, 1987,
1988, 1989 Regents of the University of California.
Table of contents
About this manual
Supported release version updates (RVUs)
Intended audience
New and changed information
Related information
Publishing history
Introduction
Java HotSpot server virtual machine
Java Development Kit (JDK)
Associated Java based products
JDBC drivers for NonStop SQL database access
JToolkit for NonStop servers
Enscribe API for Java
Pathway API for Java
Pathsend API for Java
Scalable TCP/IP
NonStop servlets for JavaServer pages
Stored procedures in Java
Installation and configuration
Pre-installation tasks
Installing NSJ11
Placing the new software on the NonStop system
Extracting script and PAX files of NSJ11
Installing NSJ11 using the scripts
Post-installation tasks
Updating the Time Zone Id string
Verifying the Java installation
Configuring NonStop system for NSJ11
Creating larger or additional swap file
Setting environment variables
Verification of network configuration
NSJ11 directory structure
Directory contents
Demonstration programs
Getting started
Specifying the CPU and process name
Configuring a Java Pathway serverclass
ARGLIST
PROCESSTYPE
ENV
PROGRAM
Implementation specifics
Log event numbers to the EMS subsystem
Adding custom logging level
Installing the EMS templates for NSJ
Using the sample
Zero-preparation VerboseGC
Enabling use of AES processor instructions
Enabling use of CLMUL processor instructions
Disabled background compilation
SHA-1 signed JARs
Removing restrictions on SHA-1 signed JARs
Headless support
NonStop specific Java libraries and binaries
Emslogger
Perf.attach
Enable JMX monitoring on a range of port value
mmaphelper
Transports
Hewlett Packard Enterprise Extensions to Standard Java Options
Hewlett Packard Enterprise Extensions to NonStandard Java Options
Java Flight Recorder (JFR)
JFR recording file name
Configuring the temporary directory for recordings
Viewing JFR recordings
Java native interface (JNI)
Calling C or C++ routines from Java
Calling Java methods from C or C++
Linker and compiler options
Compiler options
Linker options
How to create your own library of native code
Floating-point implementation
Floating-point values
Double-precision values
Calling TNS floating-point functions from JNI code
Multi-threaded programming
Thread scheduling
Dynamic thread time slice policy
Options
TimeSlicePolicy
ThreadTimeSliceMin
ThreadTimeSliceDecrement
ThreadTimeSlicePercent
DynamicThreadPriority
RestoreTimeSliceandPriority
Threading considerations for Java code
Threading considerations for native code
ThreadDumpPath support
Using the Guardian printer
Dynamic saveabend file creation
Saveabend file generation
Default process launch mechanism
Java getLocalHost() caching
Java authentication and authorization service
JavaBeans
Dejavu fonts
Debugging Java programs
Debugging overview
Transports
Java command-line options to run a debuggee
Starting the Java debugger (JDB) tool
Debugging JNI code
Debugging Java and JNI code
Deviations in JVM specification options
java: Java application launcher command-line option deviations
jdb: Java debugger command-line option deviations
Garbage collection (GC)
General information on garbage collection
Heap Layout
Heap layout for Parallel and CMS GC
Managing generation size
Implementation of garbage collector types
Parallel collector
Concurrent Low-Pause collector
G1GC collector
Handling large GC log files
Memory management considerations
JVM data segment for NSJ11
Java heap size with NSJ11
Native heap size with NSJ11
Java garbage collector tuning for application performance
javahelper
Unhandled exception
Java process name
Using JDK
GC profiling
GC log rotation
-XX:+HeapDump and _JAVA_HEAPDUMP environment variable
Other HeapDump options
Using heap dumps to monitor memory usage
Large heap support
Posting signals to javahelper process
Java signal handlers
Error file
ErrorFile with %p option
System property
LogVMOutput option
SecureRandom startup enhancement
VirtualMachine.list() support
Change in loading of .hotspot_compiler and .hotspotrc files
Precompilation enhancement
Using command line
Using CompileCommandFile command
UseCompilerProcess option
MOVBE Option
Process Timer Granularity Option
Java print service
Transactions
Controlling maximum concurrent transactions
Current class methods
Application tuning and profiling
Profiling application performance
Collecting profile data for analysis
-Xeprof
Zero preparation profiling
Obtaining garbage collection data for analysis
Other profiling options
Tuning application performance
Determining the heap size setting
Migrating applications
Summary of migration changes
Installation changes
Installation changes
Java based JAR file locations
NSJ Specific Tools
nsjps
Synopsis
-Xeprof
Synopsis
—Xverbosegc
Synopsis
-Xverbosegc:help for NSJ 11
Unsupported tools
Websites
Support and other resources
Accessing Hewlett Packard Enterprise Support
Accessing updates
Remote support
Customer self repair
Warranty information
Regulatory information
Documentation feedback
Supported and unsupported features of NSJ11
Features not implemented in NSJ11
Nonstandard Java Options
Deviations from Nonstandard Java Options
About this manual
This manual identifies the changes in the HPE adaptation of the reference Java implementation, emphasizing the differences between the reference
implementation and NSJ 11 Update3 (U3).
This manual describes the HPE NSJ, based on Java OpenJDK 11.0.18, a Java environment that supports compact, concurrent, dynamic, and portable programs
for the enterprise server. NSJ11 uses the HPE NonStop OS to add scalability and program persistence to the Java environment.
IMPORTANT: From L23.08 onwards, the NSJ11 Tools Reference Pages content has been merged into this document.
IMPORTANT: From L22.09 onwards, the NSJ 11 Programmer's Reference is renamed as the NSJ 11 User Guide (the current document).
Product version
NSJ11
For more information on the standard architecture, see JDK 11 Documentation .
JDK 11 Documentation.
Supported hardware
HPE NonStop X Servers
HPE Virtualized NonStop Servers
HPE Converged Virtualized NonStop Servers
Subtopics
Supported release version updates (RVUs)
Intended audience
New and changed information
Related information
Publishing history
Supported release version updates (RVUs)
This manual supports L21.06 and all subsequent L-series RVUs until otherwise indicated by its replacement publications.
Intended audience
This manual is for the Java programmers who want to use Java on HPE NonStop systems.
Programmers developing Java applications on NonStop systems must be familiar with:
NonStop System fundamentals applicable to NSJ11
The Open System Services (OSS) environment
For more information, see Related information.
This manual does not provide information about the following:
The Java language and tools. For details about the Java language and tools, see JDK 11 Documentation .
Accessing SQL/MP and SQL/MX databases. For information on accessing the NonStop SQL/MP and SQL/MX databases, see JDBC Driver for SQL/MP
Programmer's Reference and JDBC Type 4 Driver Programmer's Reference for SQL/MX Release x.x .
This manual identifies the changes in the HPE adaptation of the reference Java implementation, emphasizing the differences between the reference
implementation and NSJ11.
NSJ 11 User Guide
8
New and changed information
Changes to 10-180400-13 manual
Event numbers for NSJ messages
Zero-preparation VerboseGC
Enabling AES instructions support
Disabled background compilation
SHA-1 signed JARs
Update version changes
Merged NSJ11 Tools Reference Pages content
Changes to 10-180400-12 manual
Updated Installation Instructions with NSJ 11 Update2
More Font support
Removal of validation of third party JCE providers
Changes to 10-180400-11 manual
Added implementation details of Java Flight Recorder (JFR) .
Updated G1GC collector and Features not implemented in NSJ11 for new support information.
Native Memory Tracking is supported. For more information about this feature, see OpenJDK documentation .
Added enhancements to Emslogger.
Included perf.attach feature that enables a Java application to attach to another running Java application and collect performance data. See Perf.attach.
Added mmaphelper section.
Changes to P28276-001 manual
This version is a new manual.
Related information
For background information about the features described in this manual, see following documents:
NSJ Manuals/References
HPE NonStop system computing documents
NSjmeter User Guide
HPE JToolkit for NSJ Programmer's Reference
NSJ Manuals/References
The NSJ library also includes:
NSJ 11 Tools Reference
NSJ 11 API Reference Pages
HPE NonStop system computing documents
All HPE NonStop system computing documents are available in the HPE NonStop Technical Library at Hewlett Packard Enterprise Support Center .
Publishing history
NSJ 11 User Guide
9
Part number
Published
10-180400-13 August 2023
10-180400-12 July 2022
10-180400-11 June 2021
P28276-001
May 2020
Introduction
NSJ11 provides a Java environment that supports compact, concurrent, and dynamic portable programs for the NonStop systems. NSJ11 is supported on the
NonStop Open System Services (OSS) environment. NSJ11 uses the NonStop OS to provide scalability and program persistence to the Java environment.
NSJ11 is based on OpenJDK 11.0.18. NSJ11 is available only as a 64-bit product. NSJ11 is available only on L-series.
NSJ11 is a fully compliant headless JDK.
This section discusses the following topics:
Java HotSpot server virtual machine
Java Development Kit (JDK)
Associated Java based products
Subtopics
Java HotSpot server virtual machine
Java Development Kit (JDK)
Associated Java based products
Java HotSpot server virtual machine
NSJ11 implements the HotSpot server compiler and the runtime Java HotSpot virtual machine. The HotSpot Server Java virtual machine provides a fast,
reliable technology for the enterprise server environment. For more information, see The Java HotSpot Server VM and Java Virtual Machines .
Java Development Kit (JDK)
NSJ11 consists of the following standard Java components:
Java virtual machine (VM) based on OpenJDK 11.0.18
Core Packages of the OpenJDK 11.0.18
OpenJDK 11.0.18 tools as documented in the NSJ11 Tools Reference Pages . All standard tools are supported, except GUI such as appletviewer,
policytool, and jconsole , and client-side tools such as javaws and HtmlConverter . Experimental tools are not supported.
OpenJDK 11.0.18 API packages
Table 1. List of packages with headless support on NSJ11
Package
Description
javax.accessibility
Defines a contract between UI components and technology that
provides access to these components.
javax.swing and Swing-related packages
Provides a set of Java components, which works in the similar mode
on all platforms.
NSJ 11 User Guide
10
If a call is made to the code that depends on a keyboard, display, mouse, or sound processing, NSJ11 throws a java.awt.HeadlessException .
Associated Java based products
Consider a scenario in which you develop a standard Java application and then deploy and run them on NonStop servers. You can develop these applications
by using a wide range of associated Java based products that can use the NSJ11 runtime. The products are as follows:
JDBC drivers for NonStop SQL database access
JToolkit for NonStop servers
NonStop servlets for JavaServer pages
Stored procedures in Java
The following figure illustrates the high-level middleware products that appear to work with NSJ11 and NonStop SQL databases.
Figure 1. Java based products on NonStop systems
Subtopics
JDBC drivers for NonStop SQL database access
JToolkit for NonStop servers
NonStop servlets for JavaServer pages
Stored procedures in Java
NSJ 11 User Guide
11
JDBC drivers for NonStop SQL database access
JDBC drivers implement JDBC API and provide access to NonStop SQL databases. You can use JDBC API calls in your Java programs to access SQL tables on
NonStop systems. The following drivers are available:
Type 2 - a native API driver to use in Java programs running with NSJ on a NonStop system. The type 2 driver is installed using SUT.
JDBC Driver for NonStop SQL/MX (JDBC/MX)
JDBC Driver for NonStop SQL/MP (JDBC/MP)
Type 4 - a network protocol built in the database engine. Type 4 driver communicates directly to the database using Java sockets. You can use the HPE
NonStop JDBC Type 4 Driver in Java programs running on PCs, HP-UX systems, and other platforms for access to NonStop SQL/MX. For the latest list of
supported platforms, see current JDBC Type 4 Softdoc, which can be found online by accessing Scout for NonStop Servers.
For more information, see the JDBC Manuals.
JToolkit for NonStop servers
The HPE JToolkit for NonStop Servers includes three APIs as tools for using Java programs to access legacy applications on NonStop servers. JToolkit
includes Scalable TCP/IP (SIP) for developing network servers written in Java. For more information, see HPE JToolkit for NSJ Programmer's Reference .
Subtopics
Enscribe API for Java
Pathway API for Java
Pathsend API for Java
Scalable TCP/IP
Enscribe API for Java
The Enscribe API for Java allows access to the Enscribe Database Manager, supported by the Guardian file system. This access is typically used to interact
with legacy applications.
Pathway API for Java
The Pathway API for Java provides access to a file called $RECEIVE , which is required to enable a process to act as a Pathway server. These servers are
typically used in legacy applications. Pathway server programs read requests from requestor programs and act on those requests. The Guardian requestor or
server model is described in the TS/MP 2.5 Pathsend and Server Programming Manual .
A process sends a message to another process by opening the recipient process file and writing a message to it. Because a process might not know in advance
which processes send messages to it and in which order, all messages to a process arrive using a single file system connection. Reading from $RECEIVE a
process receives a message whether the message is a request from another user process or a system message.
Pathsend API for Java
The NonStop TS/MP product supports the use of Pathway servers to access NonStop SQL or Enscribe databases in an online transaction processing (OLTP)
environment. Using the Pathsend API for Java, programs can send requests to these Pathway servers and receive replies from them. Pathway servers are
written in C, COBOL, or Java.
NSJ 11 User Guide
12
Scalable TCP/IP
Scalable TCP/IP (SIP) for the NSJ provides a transparent way to provide the NonStop fundamentals of scalability and persistence to a network server (SIP
server) written in Java. Existing servers written in Java and their clients can take advantage of SIP without being changed.
NonStop servlets for JavaServer pages
NonStop Servlets for JavaServer Pages (NSJSP) are platform-independent server-side programs that programmatically extend the functionality of web-based
applications by providing dynamic content from a Web Server to a client browser over the HTTP protocol. NSJSP is an extension of that servlet functionality,
primarily supplying a template of static content to be modified with dynamic content from a servlet or another programmable resource.
NSJSP requires the use of the iTP Secure WebServer, which is based on Tomcat. Tomcat implements the Java Servlet and JavaServer Pages specifications. For
more information about NSJSP, see NonStop Servlets for JavaServer Pages (NSJSP) System Administrator's Guide . For more information about the iTP
Secure WebServer, see iTP WebServer System Administrator's Guide.
Stored procedures in Java
Stored procedures in Java (SPJs) provide an efficient and secure way to implement business logic in an SQL/MX database. They allow you to write portable
applications in Java and access an industry-standard SQL database.
An SPJ is a type of user-defined routine (UDR) that operates within a database server. A UDR can be either a stored procedure, which does not return a value
directly to the caller, or a user-defined function, which does return a value directly to the caller. (A stored procedure returns a value only to a host variable or
dynamic parameter in its parameter list.)
In the SQL/MX database, an SPJ is a Java method contained in a Java class, registered in SQL/MX, and invoked by SQL/MX when an application issues a CALL
statement to the method.
For more information on using SPJs, see SQL/MX Guide to Stored Procedures in Java .
Installation and configuration
Procedure
1. Pre-installation tasks
2. Installing NSJ11
3. Post-installation tasks
4. Configuring NonStop system for NSJ11
5. NSJ11 directory structure
Subtopics
Pre-installation tasks
Installing NSJ11
Post-installation tasks
Configuring NonStop system for NSJ11
NSJ11 directory structure
Pre-installation tasks
Procedure
1. Back up all the files, including security certificates (cacerts) and other user modified files in the NSJ11 installation directory (<Installdir>/jdk110_l11) .
NSJ 11 User Guide
13
This is the default installation location. It can be modified, as required.
If this is the first installation of NSJ11u3, skip this step.
2. To copy the backed up files, use the following command:
cp -R /usr/tandem/nssjava/jdk110_l11 /usr/tandem/nssjava/jdk110_l11.old
The following error is displayed if non-super user or the user without access permission attempts installing NSJ11 on the same path as earlier versions:
Permission denied
Hewlett Packard Enterprise recommends renaming earlier versions of NSJ installation and installs the NSJ11 version as a new installation. Files that were
modified in the earlier versions of NSJ can be copied to the NSJ11 directory.
3. The user can restore the modified and earlier versions.
Installing NSJ11
Prerequisites
NSJ11 can be installed only on NonStop systems running on L21.06 RVU and later versions.
Read the softdoc before installing the product as the required software SPRs are described in NSJ11 product softdoc.
About this task
Installation of NSJ11 is as follows:
Procedure
1. Placing the new software on the NonStop system using DSM/SCM.
2. Extracting script and PAX files for NSJ11.
3. Installing NSJ11 using the installation script.
Subtopics
Placing the new software on the NonStop system
Extracting script and PAX files of NSJ11
Installing NSJ11 using the scripts
Placing the new software on the NonStop system
About this task
Using Distributed Systems Management/Software Configuration Manager (DSM/SCM), perform the following steps:
Procedure
1. Receive the SPR from disk or tape.
2. Copy the SPR to a new revision of the software configuration which is being updated.
3. Build and apply the configuration revision.
4. Run ZPHIRNM to perform the rename step.
DSM/SCM places the pax file in $tsvvol.ZOSSUTL subvolume, where tsvvol is the disk volume in which the DSM/SCM places the target
subvolumes (TSVs)
Extracting script and PAX files of NSJ11
NSJ 11 User Guide
14
Procedure
1. The DSM/SCM planner interface with the Manage OSS Files check box selected. Using this method NSJ11 JDK files are extracted to the default or
standard location.
For example, /usr/tandem/nssjava/javainstall/$(VPROC_STR)
VPROC_STR
is vproc of the product.
For example, the VPROC of T3066 is T3066L11_31MAR2021_jdk110_AAB_11Dec2020 .
The following files are extracted:
NSJInstall - an installation script to install JDK from the JDK PAX file.
T3066IPAX - JDK installation PAX file.
2. If Manage OSS Files is not selected, DSM/SCM places the PAX file to the TSV ( $tsvvol.ZOSSUTL ). Using PINSTALL, manually extract the contents
of the PAX file to the javainstall directory.
PINSTALL - a tool for extracting files from tar (pax) files in the Guardian environment into the OSS FileSystem. This tool is a part of OSSUTILS and
resides in the sub volume $SYSTEM.SYS<NN> .
For more information on PINSTALL, see DSM/SCM User Guide.
DSM/SCM extracts only the installation files, you must run the installation script to complete the installation.
Extracting PAX contents
NOTE:
Before executing the PINSTALL command, you must have write permission on the installation directory.
a. To extract at standard location, use the following command:
$TSVVOL.ZOSSUTL > PINSTALL -rvf /G/tsvvol/zossutl/T3066PAX
PINSTALL delivers the contents of T3066PAX into the following OSS directory location:
/usr/tandem/nssjava/javainstall/$(VPROC_STR)
b. To extract NSJ11 U3 pax contents in a non-standard location, use the following command:
$TSVVOL.ZOSSUTL > PINSTALL -s:/usr/tandem:<Install-dir>:
-rvf /G/tsvvol/zossutl/T3066PAX
PINSTALL delivers the contents of T3066PAX into the following OSS directory location:
<Install-dir>/nssjava/javainstall/$(VPROC_STR)
For example, to extract the PAX file contents in the location /home/mynsj , use the following command:
$TSVVOL.ZOSSUTL > PINSTALL -s:/usr/tandem:/home/mynsj: -rvf /G/tsvvol/zossutl/T3066PAX
PINSTALL delivers the contents of T3066PAX into the following location:
/home/mynsj/nssjava/javainstall/$(VPROC_STR)
Installing NSJ11 using the scripts
About this task
NOTE: Installation of NSJ11 does not require a system generation, and does not require a cold-load.
Procedure
1. To install NSJ11 at a standard location, use the following command:
>sh $(SCRIPT_LOCATION)/NSJInstall -timezone <TZ_string>
Optional TZ_string is the Time Zone ID string corresponding to the Time Zone of the system.
NSJ 11 User Guide
15
NSJ11 is installed at the location:
/usr/tandem/nssjava/jdk110_l11
A new file timezone is created in /usr/tandem/nssjava/jdk110_l11/conf folder with the provided Time Zone ID string (if it matches with
the system Time Zone).
2. To install NSJ11 at a non-standard location, use the following command:
>sh $(SCRIPT_LOCATION)/NSJInstall <custom location> -timezone <TZ_String>
NSJ11 is installed at the specified location:
<custom location>/nssjava/jdk110_l11
A new file timezone is created in <custom location>/nssjava/jdk110_l11/conf with the provided Time Zone ID string (if it matches
with the system Time Zone).
If Time Zone ID string does not match with the system time zone or if it is not provided during installation, the timezone file is updated with the string
UseDefault .
If a java based application uses TimeZone APIs and the Time Zone ID string for NSJ is not set using any one of the following options:
a. Using TZ environment variable
b. Using user.timezone java system property
c. Using setDefault method of TimeZone class
d. Using the content of <Install-dir>/conf/timezone file
then, NSJ returns the default Time Zone ID in GMToffset format.
If Time Zone ID string is set explicitly to null, time zone related APIs return output as "GMT" instead of GMToffset, even if the system has non-zero
GMToffset.
If a correct Time Zone ID string corresponding to the time zone on the system fails with validation, run
TZupdater tool and run UpdateTimeZone
script to select the Time Zone ID string corresponding to the time zone on the system.
Post-installation tasks
Subtopics
Updating the Time Zone Id string
Verifying the Java installation
Updating the Time Zone Id string
About this task
The method to obtain the Time Zone ID string was modified during the previous release update (NSJ11 U2). Time Zone ID string corresponding to the system
Time Zone is fetched from a file called timezone residing in the <Install-dir>/conf/ folder. Default location of NSJ timezone is
/usr/tandem/nssjava/jdk110_l11/conf/timezone . This file is created during the installation of NSJ. The contents of this file is modified by
UpdateTimeZone present in <Install-dir>/install folder. This timezone file must not be modified manually. The contents of this file are
modified by the UpdateTimeZone script in <Install-dir>/install/ .
Procedure
1. Navigate to the <Install-dir>/install directory.
2. Run the UpdateTimeZone script:
> sh UpdateTimeZone
NSJ 11 User Guide
16
A list of Time Zone ID strings appears corresponding to the Time Zone IDs of the system.
3. Select the number corresponding to the Time Zone ID string for the NSJ.
If a valid value is selected, the timezone file is updated with the corresponding Time Zone ID string.
If the selection is incorrect, the content of the timezone file is not updated and the script exits with a warning.
Verifying the Java installation
Check with your system administrator for the installed NSJ11 software locations, and verify the installation and the environment. This example assumes that
NSJ11 is installed in a nonstandard location for L-series /home/mynsj/nssjava/jdk110_l11/bin/java directory:
NOTE:
For more information about the OS requirements, see T3066 Softdoc.
1. Set the PATH environment variable by using the following command at the OSS prompt:
$ export PATH=/home/mynsj/nssjava/jdk110_l11/bin:$PATH
2. Confirm that the path is set correctly by entering the whence command:
whence java
/home/mynsj/nssjava/jdk110_l11/bin/java
3. Determine the version of NSJ using the following command: vproc /h/myjava/nssjava/jdk110_l11/bin/java
The following information is displayed:
T3066L11_14FEB2021_jdk110_AAB_19Oct2020
4. To view the details of Java runtime environment and VM, specify java -version .
openjdk version "11.0.18" 2022-04-19 LTS
OpenJDK Runtime Environment (build 11.0.18+0-LTS)
OpenJDK 64-Bit Server VM (build 11.0.18+0-LTS, mixed mode)
Configuring NonStop system for NSJ11
Configure your system using the following:
Creating larger or additional swap file
Setting environment variables
Verification of network configuration
#GUID-D7147C7F-2016-0901-026D-000000000555
Subtopics
Creating larger or additional swap file
Setting environment variables
Verification of network configuration
Creating larger or additional swap file
HPE recommends that the swap file size must be equal to the physical memory size, for each processor that runs the Java virtual machine (JVM). If you plan
to run multiple large processes in the same processor, you must create additional swap files because processes running in the same processor share the swap
file.
NSJ 11 User Guide
17
Your system administrator can use the NSKCOM tool to create additional swap files.
To add swap files, you must log on to your NonStop OS as a super.super user. Then, from the Guardian TACL prompt, run the NSKCOM tool. From the
NSKCOM tool, use the help add and help start commands to get more information. For further information, see Kernel-Managed Swap Facility
(KMSF) Manual.
NOTE:
When using the large Java heap feature provided by NSJ11, HPE recommends that a contiguous block of Kernel-managed swap space that
is at least greater than the Java heap size be available.
Setting environment variables
Set the following environment variables on the NonStop System:
PATH
CLASSPATH
_RLD_LIB_PATH : To set native library path for DLLs
For more information about setting classpath, see the documentation on Oracle (Java Tools and Utilities) .
Verification of network configuration
Use the following command to ensure that the network is configured correctly:
javachk binary from <path>
If it is configured incorrectly, see the TCP/IP manuals.
TCP/IP, its components, and DNS must be configured properly. This is mandatory for any network related JDK APIs.
NSJ11 directory structure
This section provides information about the directory structure of NSJ11 and it explains the following topics:
Directory contents
Demonstration programs
Subtopics
Directory contents
Demonstration programs
Directory contents
The directory <Install-dir>/nssjava/jdk110_l11 contains release documents and subdirectories contains release documents and
subdirectories.
Table 1. Subdirectories of the /usr/tandem/nssjava/jdk110_l11 directories
NSJ 11 User Guide
18
Table 1. Subdirectories of the /usr/tandem/nssjava/jdk110_l11 directories
Subdirectory
Contents
/legal
Contains the Copyright and Legal information about the product.
/bin
Executable binary files that are present in the JDK. These files include tools that are not part of the Java SE
Runtime Environment, for example such as javac .
/demo
Other subdirectories, each containing a README file, and a complete example.
/include
C-language header files that support native code programming using the Java Native Interface and Java Virtual
Machine Interface.
/install
The javachk file. Added the UpdateTimeZone script. This script is used to modify the content of the
timezone file.
Contains the javachk binary and the UpdateTimeZone script.
/lib
Contains dynamically linked native libraries, certificates, fonts, and timezone database.
/jmods
Contains compiled module definition files.
/conf
Contains security, net, and management properties files that users can edit for customizing the installation.
timezone - file contains system timezone name. This can be updated using the <Installdir>/install/UpdateTimeZone. script. This file must not be edited manually.
Demonstration programs
The /demo directory contains subdirectories, each of which contains a demonstration program and a README file that documents how the demonstration
program must be used.
Table 1. Demonstration programs available in NSJ11
Demonstration Program
Description
/demo/emslogging
How to write to EMS Event Log. Contains source and Makefile to build demo program that will log to
EMS Event Log.
/demo/invocation_api
How to properly build an executable that can create its own Java virtual machine (JVM). Contains source
and Makefile to create invocation API demo.
/demo/nsjjni
How to create a native library. Contains source and Makefile to create nsjjni demo.
Many of the demonstration programs require editing files before the demonstration programs can be run, as described in README .
Getting started
Although this manual assumes that you are familiar with using Java and HPE NonStop Open System Services (OSS), this section provides background
information for those who are not familiar with these products. Additionally, this section explains how to perform common tasks that are characteristic to
running Java applications on NonStop systems. The topics are:
Specifying the CPU and process name
Configuring a Java Pathway serverclass
Subtopics
Specifying the CPU and process name
Configuring a Java Pathway serverclass
NSJ 11 User Guide
19
Specifying the CPU and process name
You can specify which CPU an application process runs in and its process name by using options of the run utility. The run utility starts OSS programs
with specific attributes.
Use the following command to specify the CPU where a Java application is to run:
run -cpu=<cpu_number> java <class_name>
For example:
$run -cpu=3 java HelloWorld
Use the following command to run a java process as named process:
run -name=/G/<process_name> java <class_name>
For example:
$run -name=/G/appj java MyClass
where,
the /G directory identifies the Guardian fileset.
For information about the /G directory, see Open System Services User's Guide .
The following example combines more than one run option in a single command:
$run -name=/G/appj -cpu=3 java MyClass
For more information on using -name option, see Java process name.
For more information on creating a pathway environment to run oss application as a pathway serverclass, see the latest TS/MP System Management Manual.
Configuring a Java Pathway serverclass
To run a Java application as a pathway serverclass, serverclass configuration must be set. The following section describes configuration parameters specific
to run Java application in pathway environment.
For complete information on how to run an OSS application in pathway environment, see the latest TS/MP System management Manual .
Subtopics
ARGLIST
PROCESSTYPE
ENV
PROGRAM
ARGLIST
Use ARGLIST parameter of serverclass to set the Java options, application name, arguments to the Java application in this order.
The ARGLIST must be in the form:
where, java_options is of the following format
--Xabend <java_options> java_options specifies multiple comma separated list of Java options.
-Xabend is mandatory
application_name is the name of the Java application
application_arguments is the list of arguments to the Java application.
<java_options>,<application_name>,<application_arguments>
-Xabend,class-name[,arguments]
where, [,arguments] is an optional, comma-separated list of arguments that are passed to the named serverclass.
For example, from the OSS prompt, start a PATHMON (process monitor) named $foo and set the ARGLIST at the PATHCOM prompt:
NSJ 11 User Guide
20
$gtacl -p pathcom \$foo
PATHCOM .....
=set serverclass ARGLIST -Xabend,MyClass,3000
This is similar to entering java -Xabend MyClass 3000 at an OSS shell prompt. The -Xabend argument to the java executable causes
java to abend instead of exiting with a non-zero exit code. Pathway servers must abend rather than merely stop when a fatal error occurs, so that the
PATHMON process can restart them. MyClass is the name of the Java class to be initiated, and "3000" is an argument to the MyClass class.
NOTE:
In the OSS environment, the dollar sign ( $ ) has special meaning; therefore, the process name $foo is preceded by a backslash ( \ ), the
escape character.
PROCESSTYPE
Set this attribute to OSS .
ENV
Environment variables are set using the ENV serverclass attribute. For Java use, you must set the CLASSPATH environment variable so that the Java
runtime can find your classes. For a CLASSPATH example, the following set server command is entered at the PATHCOM prompt.
$gtacl -p pathcom \$foo
...
...
=set server ENV CLASSPATH=/myclasspath
where, /myclasspath is the location where all the classes are available.
PROGRAM
Set the PROGRAM attribute to the java executable. The java executable is located by default in /usr/tandem/nssjava/jdk110_l11/bin .
For example, from the OSS prompt, start a PATHMON (process monitor) named $foo and set the PROGRAM attribute at the PATHCOM prompt:
$gtacl -p pathcom \$foo
...
...
set server PROGRAM /usr/tandem/nssjava/jdk110_l11/bin/java
Implementation specifics
This section explains the various topics pertaining to the implementation specifics of NSJ.
NSJ 11 User Guide
21
Log event numbers to the EMS subsystem
Using the Guardian printer
Zero-preparation VerboseGC
JavaBeans
Enabling use of AES processor instructions
Dejavu fonts
Enabling use of CLMUL processor instructions
NonStop specific Java libraries and binaries
Disabled background compilation
Emslogger
SHA-1 signed JARs
Deviations in JVM specification options
Headless support
Perf.attach
Java print service
System property
Pthreads library
ThreadDumpPath support
Default process launch mechanism
Native Interface
Java native interface (JNI)
Floating-point implementation
Threads
Multi-threaded programming
Diagnostics and profiling
Java Flight Recorder (JFR)
Caching
Java getLocalHost() caching
Garbage collection
Dynamic saveabend file creation
Saveabend file generation
Garbage collection (GC)
Memory management considerations
Java garbage collector tuning for application performance
javahelper
GC profiling
Large heap support
Error file
LogVMOutput option
Debugging Java
Debugging Java programs
Authentication and authorization
Java authentication and authorization service
Java command-line options to run a debuggee
Starting the Java debugger (JDB) tool
Debugging JNI code
Debugging Java and JNI code
Signals
Posting signals to javahelper process
Java signal handlers
Miscellaneous
SecureRandom startup enhancement
VirtualMachine.list() support
Change in loading of .hotspot_compiler and .hotspotrc files
Precompilation enhancement
UseCompilerProcess option
UseCompilerProcess option
Process Timer Granularity Option
Subtopics
Log event numbers to the EMS subsystem
Zero-preparation VerboseGC
NSJ 11 User Guide
22
Enabling use of AES processor instructions
Enabling use of CLMUL processor instructions
Disabled background compilation
SHA-1 signed JARs
Headless support
NonStop specific Java libraries and binaries
Emslogger
Perf.attach
Enable JMX monitoring on a range of port value
mmaphelper
Transports
Hewlett Packard Enterprise Extensions to Standard Java Options
Hewlett Packard Enterprise Extensions to NonStandard Java Options
Java Flight Recorder (JFR)
Java native interface (JNI)
Floating-point implementation
Multi-threaded programming
ThreadDumpPath support
Using the Guardian printer
Dynamic saveabend file creation
Saveabend file generation
Default process launch mechanism
Java getLocalHost() caching
Java authentication and authorization service
JavaBeans
Dejavu fonts
Debugging Java programs
Deviations in JVM specification options
Garbage collection (GC)
Memory management considerations
Java garbage collector tuning for application performance
javahelper
Java process name
GC profiling
Large heap support
Posting signals to javahelper process
Java signal handlers
Error file
NSJ 11 User Guide
23
System property
LogVMOutput option
SecureRandom startup enhancement
VirtualMachine.list() support
Change in loading of .hotspot_compiler and .hotspotrc files
Precompilation enhancement
UseCompilerProcess option
MOVBE Option
Process Timer Granularity Option
Java print service
Log event numbers to the EMS subsystem
The section describes the logging event numbers for the messages other than the fixed ones to the EMS subsystem. NSJ provides following handlers to
generate the messages to the EMS collector:
com.tandem.logging.EmsTextHandler : This handler sends text messages to the EMS collector.
com.tandem.logging.EmsTokensHandler : This handler sends the tokenized message to the EMS collector with fixed event number
(000001). This requires EMS template for NSJ to be installed on the system.
com.tandem.logging.EmsEventIdsTokensHandler : This handler sends the tokenized message to the EMS collector with an ability to
generate event numbers other than the fixed one. This requires EMS template for NSJ to be installed on the system.
A sample EMS template source file sl5jtmpl for NSJ is packaged with NSJ and it is available in the <install-dir>/demo/emslogging
directory on the NonStop System. <install-dir> is seen as the NSJ installation directory. For example: /usr/tandem/nssjava/jdk110_l11 .
By default, sl5jtmpl file contains the following template:
MSG: ZEMS-TKN-EVENTNUMBER, 1
"Utility: <1>, "
"Level: <2>, "
"Message: <3>"
"<*IF 8>, Logger: <4><*ENDIF>"
"<*IF 9>, Source: <5>.<*ENDIF>"
"<*IF 10><*IF 11>, Source: <*ENDIF><6>()<*ENDIF>"
"<*IF 12>, Exception: <7><*ENDIF>"
1: ZL4J-TKN-UTILITY
2: ZL4J-TKN-LEVEL-NAME
3: ZL4J-TKN-LOG-MSG
4: ZL4J-TKN-LOGGERNAME
5: ZL4J-TKN-CLASS-NAME
6: ZL4J-TKN-METHODNAME
7: ZL4J-TKN-EXCEPTION-TRACE
8: TOKENPRESENT(ZL4J-TKN-LOGGERNAME)
9: TOKENPRESENT(ZL4J-TKN-CLASS-NAME)
10: TOKENPRESENT(ZL4J-TKN-METHODNAME)
11: NOT TOKENPRESENT(ZL4J-TKN-CLASS-NAME)
12: TOKENPRESENT(ZL4J-TKN-EXCEPTION-TRACE)
This template accepts and prints the fixed event number for each message sent to the EMS collector. This is the behavior of the
com.tandem.logging.EmsTokensHandler .
To send event numbers other than the fixed event number using handler
specific templates installed on the system.
com.tandem.logging.EmsEventIdsTokensHandler , we must have
For example:
MSG: ZEMS-TKN-EVENTNUMBER, ZL4J-VAL-LEVEL-SEVERE
"Utility: <1>, "
"Level: <2>, "
NSJ 11 User Guide
24
"Message: <3>"
1: ZL4J-TKN-UTILITY
2: ZL4J-TKN-LEVEL-NAME
3: ZL4J-TKN-LOG-MSG
This template sends the event number associated with logging level SEVERE. Similarly, this source template file must have other templates corresponding to
each individual event number.
Value for constant ZL4J-VAL-LEVEL-SEVERE is defined in the file zl5jddl .
DDL file zl5jddl , can have a definition for custom levels too. Sample DDL file zl5jddl is also packaged with NSJ at <installdir>/demo/emslogging .
Both sl5jtmpl and zl5jddl are sample files and NSJ user must change these, as required. After these files are updated, these templates must be
reinstalled on the system using install.EMS . script in <install-dir>/demo/emslogging .
Subtopics
Adding custom logging level
Installing the EMS templates for NSJ
Using the sample
Adding custom logging level
About this task
The EMS module uses java.util.logging framework to log the messages. It supports the following levels, in descending order:
SEVERE (highest value)
WARNING
INFO
CONFIG
FINE
FINER
FINEST (lowest value)
To support custom logging level, changes are required.
Procedure
1. Add an entry in the zl5jddl file for the custom logging level:
! ZL4J-VAL-LEVEL-DEBUG is the custom logging level
CONSTANT ZL4J-VAL-LEVEL-DEBUG
VALUE IS 1100.
IMPORTANT: DEBUG is a custom logging level.
2. Log the message to the EMS subsystem. Add a message template to the sl5jtmpl file for the DEBUG level as follows:
==----------------------------------------------------------------------------==ZL4J-VAL-LEVEL-DEBUG with value 1100, EmsEventIdsTokensHandler sends messages
==to this template
==This is a custom level
==----------------------------------------------------------------------------MSG: ZEMS-TKN-EVENTNUMBER, ZL4J-VAL-LEVEL-DEBUG
"Utility: <1>, "
"Level: <2>, "
"Message: <3>"
1: ZL4J-TKN-UTILITY
2: ZL4J-TKN-LEVEL-NAME
3: ZL4J-TKN-LOG-MSG
After completing these steps, proceed with the template installation.
NSJ 11 User Guide
25
The application with a custom logging level is effective after the new templates are installed.
Installing the EMS templates for NSJ
Prerequisites
Check if any of the following files are open:
$SYSTEM.ZL5J.NEWNRES
$SYSTEM.ZL5J.NEWRES
$SYSTEM.ZL4J.NEWNRES
$SYSTEM.ZL4J.NEWRES
If yes, execute the following from the TACL prompt:
scf alter subsys $ZZKRN,nonresident_templates $system.system.template
scf alter subsys $ZZKRN,resident_templates $system.system.rtmplate
These commands set the system templates from the standard location. This closes the files from
new template files at $SYSTEM.ZL5J using new source template files.
$SYSTEM.ZL5J or $SYSTEM.ZL4J . This generates
Procedure
Execute the following script from <install-dir>/demo/emslogging./install.EMS :
//start of the script run log
To install NonStop Server for Java EMS Template, you must be a SUPER.SUPER user.
Checking your user privilege ...
This installation will merge NonStop Server for Java EMS Template with
the system template.
Do you want to continue?[y/n]: y
Enter the ISV volume (without the $) where the zspidef subvol
is located (often SYSTEM): SYSTEM
Installing NonStop Server for Java EMS Template ...
Building and installing EMS templates. This may take 5 minutes ...
SCF W20052 Creating file \YAMUNA.$SYSTEM.ZL5J.TEMPXYZ
SCF W20052 Creating file \YAMUNA.$SYSTEM.ZL5J.LSCF
Installation done!
//end of the script run log
The script merges the system template file with NSJ EMS template file. It also sets the properties of
$zzkrn for the template files.
After the EMS template for NSJ is successfully installed the following messages are seen on the EMS collector for the Java sample. This sample has DEBUG as
a custom logging level. These messages have different event numbers which are associated with their logging levels.
23-06-08 11:02:04 \YAMUNA.2,902
TANDEM.JAVALOG.H50
000800
Utility: BusyBee-Utility, Level: INFO,
Message: This is an INFO level message.,
Logger: WorkerEventId
23-06-08 11:02:04 \YAMUNA.2,902
TANDEM.JAVALOG.H50
000900
Utility: BusyBee-Utility, Level: WARNING,
Message: This is a WARNING level message.,
Logger: WorkerEventId
23-06-08 11:02:04 \YAMUNA.2,902
TANDEM.JAVALOG.H50
001000
Utility: BusyBee-Utility, Level: SEVERE,
Message: This is a SEVERE level message.,
23-06-08 11:02:04 \YAMUNA.2,902
Logger: WorkerEventId
TANDEM.JAVALOG.H50
001100
Utility:
BusyBee-Utility, Level: DEBUG,
Message: This is a DEBUG level message & it is a
custom level, Logger: WorkerEventId
NSJ 11 User Guide
26
Using the sample
Procedure
Use the sample at <install-dir>/bin/java WorkerEventId
Multiple samples are available as part of <install-dir>/demo/emslogging for each handler.
README file is packaged at <install-dir>/demo/emslogging and has details for each sample.
If there is no appropriate template installed on the system, the following message appears on the EMS collector:
TANDEM.JAVALOG.H50
001000 EMSTEXT -- No
template and no TEXT token for event. SSID
= TANDEM.JAVALOG.H50 Event number = 1000
Subject = BusyBee-Utility
As a corrective measure, update the sl5jtmpl file with a message template corresponding to level number 1000 .
Zero-preparation VerboseGC
Using this feature, the JVM can be prompted to provide HP verbosegc information for Java applications started without -Xverbosegc . Zeropreparation Verbosegc allows obtaining verbosegc information from the JVM by sending the SIGALRM signal to the running java program.
For example; assuming the running Java process ID is 6754, executing either of the two actions prompts the JVM to start emitting detailed
verbosegc information:
HP
kill -14 6754
kill -s alrm 6754
Issuing a second SIGALRM signal to the Java program prompts the JVM to stop emitting verbosegc information. Similarly, issuing another SIGALRM
signal to the running process prompts the JVM to start issuing verbosegc information again.
Enabling use of AES processor instructions
If the processor supports AES (Advanced Encryption Standard) instructions NSJ11, use these instructions automatically. Using processor native AES
instructions improves the performance of encryption/decryption processing significantly. This feature is enabled by default. If applications must disable it, it
must be done using the JVM command line option:
-XX:-UseAES
If AES instructions are enabled, UseAESIntrinsics is also enabled automatically.
Enabling use of CLMUL processor instructions
If the processor supports CLMUL (Carry-Less Multiplication) instructions, NSJ11 uses these instructions in calculating the CRC resulting in significant
improvement in CRC calculation. This feature is enabled by default if the underlying processor supports CLMUL instructions. If applications must disable this
feature, it must be done using this JVM command line option: -XX:-UseCLMUL , if CLMUL is enabled CRC32Intrinsics/CRC32CIntrinsics is
automatically enabled.
Disabled background compilation
In earlier NSJ releases on L-Series, background compilation is enabled by default. This negatively impacts the performance of the CPU intensive applications
as the thread that is performing compilation of the method will not get a chance to run. Due to this, the method continues to run in interpreted mode until the
CPU intensive thread gives up the CPU. The background compilation is disabled by default from NSJ11. Due to this change, JVM blocks the current thread
that is scheduled by the hotspot compilation and unblocks the thread after the hotspot compilation is over. This improves the performance of CPU intensive
applications. Blocking of the current thread for method compilation causes the application to pause until the method is compiled. The pause might be
compensated with the improvement in execution time of the method in compiled mode compared to the interpreted mode.
If applications need background compilation to be enabled, it can be enabled by using flag, -XX:+BackgroundCompilation . This prevents
application pause while the method is being compiled.
NSJ 11 User Guide
27
SHA-1 signed JARs
Starting with NSJ11, JARs signed with SHA-1 algorithms are restricted by default and treated as they were unsigned.
To reduce the compatibility risk for JARs that have been previously timestamped, the restriction does not apply to any JAR signed with SHA-1 algorithms and
timestamped prior to January 01, 2019. This exception will be addressed in a future OpenJDK release.
For determining if the JAR file is impacted by the restriction, use the following command:
$ jarsigner -verify -verbose –certs
In the output, search for instances of SHA1, SHA-1, or disabled. Also search for any warning messages that indicate that the JAR will be treated as unsigned.
For example:
Signed by "CN="Signer""
Digest algorithm: SHA-1 (disabled)
Signature algorithm: SHA1withRSA (disabled), 2048-bit key
WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled
by the security property:
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter
2019-01-01
Consider replacing or re-signing any JARs affected by the new restrictions with stronger algorithms.
If the JAR file is impacted by this restriction; remove the algorithm and re-sign the file with a stronger algorithm, such as SHA-256.
Subtopics
Removing restrictions on SHA-1 signed JARs
Removing restrictions on SHA-1 signed JARs
About this task
For NSJ11; accept the security risks, and complete the following actions:
Procedure
1. Modify the java.security configuration file.
Alternatively, you can preserve this file and instead create another file with the required configurations.
2. Remove the SHA1 usage SignedJAR & denyAfter 2019 01 011 entry from the jdk.certpath.disabledAlgorithms security
property.
3. Remove the SHA1 denyAfter 2019-01-01 entry from the jdk.jar.disabledAlgorithms security property.
Headless support
NonStop OS does not support GUI operations; making NSJ11 headless, that conforms to the OpenJDK headless mode.
NSJ11 always returns GraphicsEnvironment.isHeadless() as True . If Java programs use classes and methods that require a display,
keyboard, sound, or mouse operation; the class or method throws a headless exception.
System property, java.awt.headless is set to true by default in NSJ11.
NonStop specific Java libraries and binaries
In addition to the standard Java packages, NSJ11 provides the following files:
java.tandem.emslogger.jmod
NSJ 11 User Guide
28
This module contains Java APIs for EMS logging.
java.tandem.ext.jmod
This module consists of Java APIs for OSS Sockets library function and Java API for getting time information for NSK operation system process.
For more information, see NSJ11 API Reference Pages.
Emslogger
EmsLogger supports multibyte characters for EMS utility and level information. EMSLogger uses the encoding value set by the application for
EmsTextHandler , EmsTokensHandler , and EmsEventIdsTokensHandler to encode utility and level information and sends it to
the EMS log.
Emslogger is enhanced to log all SEVERE messages as critical when the Java option -Dnsk.java.setEmphasis is set to true . When Dnsk.java.setEmphasis is set to true , ZEMS_TKN_EMPHASIS token is set to ZSPI_VAL_TRUE and added along with the message to the EMS log.
This feature enables you to filter critical messages, if required.
Perf.attach
Perf.attach enables a Java application to attach to another running Java application and collect performance data. It involves a target process and an
attaching process.
Perf.attach works only in the following scenarios:
If the target and attaching processes are run with the current version (Give T-number and SPR) of NSJ.
If both attaching and target processes run on the same NonStop system.
In other words, if any one of the Java processes run with the earlier version of NSJ or if they run on different NonStop systems, Perf.attach will not work.
If PerfDisableSharedMem option is not specified or it is specified with a value of false, then Perf region is created by allocating a flat segment. The
segment ID used for the segment is 1073. In NSJ releases earlier than NSJ11, this segment ID is used for JVM segments on 32-bit NSJ and not used in 64-bit
NSJ. As NSJ11 is supported only in 64-bit mode, this segment is not used and hence is used for Perf.attach. The default size of the Perf region segment is 32K
(OpenJDK default). You can alter the Perf region size using the command line option –XX:PerfDataMemorySize=<size> .
When Perf.attach is used, earlier versions of NSJ raised the exception, javax_naming_OperationNotSupportedException . With the current
release, this exception does not occur and Perf.attach() succeeds if the target process had enabled allocation of Perf region in the shared memory. Since the
process that initiates Perf.attach is a Java process, it allocates Perf region segment with segment ID 1073. So the initiating process cannot share the segment
with ID 1073 on target process. To avoid this, application that initiates Perf.attach() can use -XX:+PerfDisableSharedMem , to disable allocation of
Perf data region in the shared segment. If application does not disable allocation to the shared memory region, then mmaphelper process is started. The
mmaphelper process attaches with the Perf region of the target process and communicates with the attaching process using standard NSK IPC
mechanism.
If Perf.attach uses NSK segment sharing mechanism, the security enforced is same as segment sharing mechanism enforced by NSK. If Perf.attach uses
mmaphelper , then the attacher must run with the same user ID as the target process, or with group manager ID as the target process or with super group
ID.
If Perf.attach() uses mmaphelper process, then there may be a difference in data as seen by the attaching process and target process due to usage of IPC
mechanism for data synchronization. This difference may be more if data is accessed just before synchronization. To minimize this data difference, you can
use the command line option, -XX:PerfAttachSyncTime=<value> to control how often the data is synchronized. The value specified is in number
of seconds. The default value is 1 second.
When using Perf.attach, HPE recommends that the attaching process disable the Perf region in the shared memory using XX:+PerfDisableSharedMem . It is recommended to run the attaching process on the same CPU as the target process. Also, try to limit one Perf.attach
at any time to use segment sharing mechanism.
NOTE: The allocation of performance data in shared memory is disabled for the NSJ tools except for "java". If you want to use shared
memory for performance data, then use -J-XX:-PerfDisableSharedMem while initiating the NSJ tools.
For example, initiate the javac tool as follows to enable Perf data segment to be allocated in shared region.
javac -J-XX:-PerfDisableSharedMem <class File>
For JDB, both -XX and -J-XX must be passed as -XX is used by JDB and -J-XX is used for the forked child process.
Enable JMX monitoring on a range of port value
NSJ 11 User Guide
29
To enable JMX monitoring and management from remote system, following system property can be set while starting the JVM Dcom.sun.management.jmxremote.port=portNum , where portNum is the port number through which you want to enable JMX/RMI
connections.
The System property takes only one port value, hence when it is used under a pathway server with NUMSTATIC>1, this will result in port conflict. To
overcome this, a new feature is supported on NSJ which aims at addressing the conflict issue.
Solution:
To overcome the port conflict issue, -Dcom.sun.management.jmxremote.port option is enhanced to take a range of port values. If this option is
used, then the port addresses defined within this range are used.
Usage:
-Dcom.sun.management.jmxremote.port=4000-4050
The port address within the range 4000–4050 are used, including 4000 and 4050. The first available port from minimum to maximum range is used that is, if
port 4000 is available, the address 4000 is used, if the next available port is 4002, then 4002 is used, this continues until the maximum range is reached,
which is 4050.
For a Java application running under a pathway server with NUMSTATIC=3 and the address range specified is 4000-4050, the three ports which are available
from the range 4000–4050 in the ascending order will be used.
NOTE:
This enhancement does not support list of port value that is address = 40, 4010.
mmaphelper
The mmaphelper is an executable file that is launched by JVM to enable Perf.attach to a target process if the Perf segment cannot be shared. The
mmaphelper process is a single-threaded application and it attaches to the Perf segment in the target Java process. Other than the Perf segment, it does
not share any data with the target process. It interacts with Java application using the standard NonStop Kernel IPC mechanism. The mmaphelper process
is launched on the same processor on which the perf.attach target Java process is running. You must not initiate mmaphelper executable file directly. If you
initiate it directly, the program exits without displaying any error or warning message.
The mmaphelper binary resides at the <Install-dir>/bin folder.
Transports
A Java Platform Debugger Architecture (JPDA) transport is a form of inter-process communication used by a debugger application and the debuggee. NSJ 11
provides a socket transport that uses the standard TCP/IP sockets to communicate between debugger and the debuggee.
NSJ 11 defaults to socket transport. NSJ 11 does not support shared memory transport.
Hewlett Packard Enterprise Extensions to Standard Java Options
-nsjversion
Prints the NSJ 11 build version.
Hewlett Packard Enterprise Extensions to NonStandard Java Options
-Xabend
Turns on the abend option to abort the process instead of exiting with a non-zero exit code. If the NSJ 11 application runs as a Pathway server, you can enable
this option to alert Pathmon to restart the server after NSJ 11 application closes.
-XX:+ForceStopableMode
Forces the Java process stop mode to 1 (stoppable) when a Java thread transitions to native state. Under certain rare conditions, the Java Virtual Machine
(JVM) can incorrectly be running in unstoppable mode, which can result in a processor halt if the JVM process encounters an exception. Normally, the process
stop mode is set to unstoppable by privileged code when the code is run, and set back to stoppable mode on exit to the calling routine. While Java itself does
not run in privileged mode when executing Java byte codes, Java application code as well as the JVM can make calls to native code or system APIs that run
NSJ 11 User Guide
30
privileged code. If any of these privileged routines do not reset the stop mode on exit, it can result in a processor halt if a trap occurs. Enable this flag to avoid
a processor halt in case the stop mode is set incorrectly. Some applications may see performance degradation when this flag is enabled.
Java Flight Recorder (JFR)
Java Flight Recorder (JFR) is a diagnostic and data profiling tool for Java applications. JFR is integrated into the JVM and collects data from the JVM using
internal APIs. The data collected from internal APIs and Java applications are stored in binary format in a recording file.
Differences in NSJ implementation
Due to certain NonStop Kernel (NSK) limitations, the NSJ implementation of Java Flight Recorder (JFR) is different than the implementation on other
platforms. The following are the differences in the NSJ implementation of JFR:
On other platforms, JFR provides information about all running processes in the system. With NSJ, it provides information about OSS processes only.
The /proc interface in other platforms enables the JVM to collect data. The /proc interface is not available in NSK and the JVM collects similar data
from alternative methods such as the Guardian procedure calls, OSS system, or library calls. If there are no alternative methods to collect a particular data,
it is unavailable.
NSK does not have kernel level thread support. Therefore, thread level statistics such as number of thread dispatches, thread CPU time are unavailable.
The following sections discuss JFR implementation details in NSJ:
JFR recording file name
Configuring the temporary directory for recordings
Viewing JFR recordings
For more information on JFR, see https://docs.oracle.com/.
Subtopics
JFR recording file name
Configuring the temporary directory for recordings
Viewing JFR recordings
JFR recording file name
Java Flight Recorder stores the data in a recording file in binary format. When an application ends, the data collected from the application is recorded in the
recording file if the dumponexit value is true.
If you specify the name of a directory as the filename for a recording file, the JVM creates the recording file in the specified directory. If you do not
specify the filename , the JVM creates the recording file in the current working directory.
The following is the format of the JFR file name:
hotspot-pid-<pid>-id-<id>-<yyyy>_<mm>_<dd>_<hh>_<mm>_<ss>.jfr
For example, the JFR recording file name for a process that is created on September 24, 2020 at 11:53:09 PM with PID 721420300 is
721420300-id-1-2020_09_24_23_53_09.jfr .
hotspot-pid-
You can choose to specify a Guardian file for the filename . However, the filename is restricted to eight characters in the Guardian environment. If
you specify the subvolume name for the filename , the default JFR recording filename is HOTSPOTP . If you specify a filename that has more
than eight characters, it is truncated to eight characters.
For example,
If you specify filename as /G/DATA01/JFRRECS/MYFIRSTJFR , the recording file created is named /G/DATA01/JFRRECS/MYFIRSTJ .
If you specify filename as /G/DATA01/JFRRECS/ , the recording file created is /G/DATA01/JFRRECS/HOTSPOTP .
NOTE:
If you specify only the Guardian volume name for the recording file name, the JFR recording file creation fails.
Hewlett Packard Enterprise recommends using OSS file names for the recording file.
NSJ 11 User Guide
31
Configuring the temporary directory for recordings
Naming
If the data collected by JFR resides on disk, the JVM creates a temporary directory for storing the data. The temporary directory name is in the following
format:
<yyyy>_<mm>_<dd>_<hh>_<mm>_<ss>_<pid>
For example, if the application PID is 436207628 and the process starts on September 24, 2020 at 10:32:41 PM, the temporary directory created is
2020_09_24_22_32_41_436207628 .
Location and default value
Specify the location of the temporary directory using the repository option. If you do not specify the location, the default location is obtained from the
java.io.tmpdir property. The default value for java.io.tmpdir is /tmp .
Do not specify a Guardian volume or subvolume for the repository. If you specify a Guardian subvolume, the process abends with the following message:
Error occurred during initialization of VM
Managing the temporary directory and recording data
If you specify a recording filename and set dumponexit to true, the data from the temporary directory is transferred to a recording file after the
application ends.
If the recording is not saved by setting dumponexit to true or by using the jcmd utility, the data is discarded.
If the JVM shuts down normally, the temporary directory is deleted. If you stop a process using commands such as kill -9 <pid> or gtacl -c
'stop <cpu>,<pin>' , the temporary directory is not deleted. In such cases, you must periodically delete the temporary directories.
Viewing JFR recordings
You can view JFR recording files using the jfr tool or JDK Mission Critical (JMC) version 7.0 and later.
The jfr tool is part of the JDK and is available in the same directory where the java binary file is present. Use the print option to print selected JFR
entries from the JFR recording file to a standard output file.
As JMC is a GUI tool, it is not available on the NonStop platform. To view recording files using JMC, install JMC on platforms that support GUI, for example,
Microsoft Windows. See the Oracle JMC download website for the platforms where JMC is available.
After you install JMC, you can view the JFR recording file by transferring the recording file from NonStop platform to the platform where you installed JMC.
NOTE: JMC can load JFR recording files with only .jfr extensions. If the recording file is not saved as a .jfr file while recording,
rename the file to have a .jfr extension.
Connecting to the running JVM using JMC
JMC enables you to directly connect to a running Java process on NonStop Kernel (NSK). To do so, start the application with the
Dcom.sun.managment.jmxremote system property.
–
Override the default values as per the following list:
-Dcom.sun.management.jmxremote.port=6079
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
NOTE: To connect to a running JVM on NonStop Kernel, run JMC on a system that is within the firewall. The default
number is 7095.
jmxremote port
As NSK does not have kernel level threads, Hewlett Packard Enterprise does not recommend connecting to and monitoring a running Java process using JMC.
Instead, use JFR recording features such as command line option and jcmd to create JFR recording files, transfer the JFR recording files to a Windows
platform, and view the files using JMC.
Java native interface (JNI)
The JNI is a native programming interface. It allows Java code that runs inside a Java Virtual Machine (VM) to interoperate with applications and libraries
written in other programming languages, such as C, C++, and assembly. For further information, see Java Native Interface Specification .
NSJ11 supports JNI and Invocation API with the following modifications:
NSJ 11 User Guide
32
Set the _RLD_LIB_PATH environment variable to point to the User DLL location.
export _RLD_LIB_PATH=dll-path[:dll_pathn]...
where, dll-path and dll-pathn are the User DLL directories.
For example, if the user DLLs are in the directory /home/mydll
export _RLD_LIB_PATH=/home/mydll
NSJ11 supports only the POSIX User Thread library (PUT). As a result of this, additional migration considerations arise while migrating threaded native
code to NSJ11. There are two kinds of native applications that require changes:
1. Applications that dynamically load libjvm.so and initiate JVM using Invocation APIs. For more information, see Calling Java methods from C or
C++.
2. Applications that use Pthread library to create multi-threaded application. For more information, see Threading considerations for native code .
If native C or C++ routines initiate Transaction Management Facility (TMF) calls, you must use TMF transaction jacket routines defined in “TMF
Transaction Jacket Routines” in the “Using the POSIX User Thread (PUT) Model Library” section in the Open System Services Programmer Guide .
The calls are:
PUT_ABORTTRANSACTION()
PUT_BEGINTRANSACTION()
PUT_ENDTRANSACTION()
PUT_RESUMETRANSACTION()
OSS supports a maximum of 1000 concurrent transactions in a process. However, JVM is an exception where the maximum transactions allowed are 200
as described in Controlling maximum concurrent transactions .
NSJ11 performs no conversion when calling a C or C++ routine where the function passes or returns parameters of type float or double . All
float and double values remain in IEEE floating-point format when crossing the JNI boundary. For more information, see Floating-point
implementation.
When using the JNI_OnLoad function, use the following format:
jint JNI_OnLoad(JavaVM *vm, void *reserved);
The JNI_OnUnload function is supported.
Conform to the following rules when naming user DLLs:
Do not use names that begin with Tandem , tandem , or tdm .
NSJ11 requires that all DLLs be named with a prefix lib and a suffix .so . Hence you must name your DLL as follows:
lib<name>.so
where, <name> signifies the string that is passed to the System.loadLibrary () call.
The remainder of this subsection explains:
Calling C or C++ routines from Java
Calling Java methods from C or C++
Linker and compiler options
For more information about JNI, see Oracle JNI document.
Subtopics
Calling C or C++ routines from Java
Calling Java methods from C or C++
Linker and compiler options
How to create your own library of native code
NSJ 11 User Guide
33
Calling C or C++ routines from Java
To call C or C++ routines from Java, conform to the following steps:
1. Compile the Java code.
2. Use javac -h to generate header files— The function declarations listed in the generated header file are those that must be exported by the user-JNI
DLL.
To export functions, either specify export$ in the function definition or use the linker option -export_all .
3. Compile the C or C++ code using c89 compiler. C++ code must be compiled using the compiler command-line options as explained in Linker and compiler
options.
NOTE:
JVM does not support JNI application compiled using c11 compiler.
For example:
/usr/bin/c89 -g -I /usr/tandem/nssjava/jdk110_l11/include -I /usr/tandem/nssjava/jdk110_l11/include -I. -I
/G/system/system -Wallow_cplusplus_comments -Wlp64 -Wextensions -D_XOPEN_SOURCE_EXTENDED=1 -Wnowarn=141,209
-Wcall_shared -Wsystype=oss -Wtarget=tns/x -c SystemInfo.c
If the native code has large variables on the stack, then calling this native code might exceed the default stack space provided for each thread. If the
native code exceeds the amount of stack space allocated for it, then it results SIGSTK.
To prevent overflowing the available stack space, consider allocating large variables on the heap rather than using the stack. Otherwise, you can increase
the default stack size for each thread by specifying the -Xss option when starting java . This option increases the stack size for every thread.
For more information about the -Xss option, see java in the NSJ11Tools Reference Pages.
4. Create a DLL file ( .so file type) and specify the linker option as explained in Linker and compiler options.
After specifying the linker option, set the _RLD_LIB_PATH environment variable to point to where the created DLL file resides by using the following
command:
export _RLD_LIB_PATH= dll-path
where, dll-path is the directory where the user DLL resides.
For example:
/usr/bin/xld TandemWrap.o SystemInfo.o -o libCompanySysInfo.so -set SYSTYPE OSS -set HIGHPIN ON -set
data_model lp64 -set CPlusPlusDialect neutral -dll -lcre -lcrtl -export_all
For more information, see #GUID-D7147C7F-2016-0901-0264-000000000554.
The nsjjni demo shows an example of how to create a library file, see Table: Demonstration programs available in NSJ11 to view the directory location of
the demo programs. The demo also shows the conversion between the TNS and IEEE floating-point.
Calling Java methods from C or C++
You can create your own C or C++ program. Follow these guidelines to use the Invocation API to load the JVM in an arbitrary native program:
NSJ11 supports only the POSIX User Thread library. As a result, the following issues must be considered when migrating to NSJ11:
Java application which uses the Invocation API must necessarily link with the POSIX User Thread library. An application must link with WPUTDLL .
Set the _RLD_LIB_PATH environment variable to the location of libjvm.so as shown:
$ export _RLD_LIB_PATH=$< java_home_path>/lib/server
A native application can use the JNI_CreateJavaVM() call to become a Java process, and such applications are called JNI applications. The native
application can be either multi-threaded or single threaded. If an application calls the JNI_CreateJavaVM() on the main thread, then the main
thread becomes the Java thread after creating the virtual machine. If an application already contains a VM, another thread can become a Java thread by
invoking AttachCurrentThread() . In either case, if the calling thread is the main thread and if distributed GC or compiler process is enabled, the
main thread stack must be shared by javahelper processes. As the main thread stack cannot be shared across javahelper processes, the distributed GC
cannot be enabled when the main thread is the Java thread. Hence, JNI_CreateJavaVM() and AttachCurrentThread() return
NSJ 11 User Guide
34
JNI_EUNSUPPORTED error if they are called from the main thread with distributed GC or compiler process enabled.
NOTE:
All the instances of distributed GC in this manual refer to non-serial GC. For more information, see Garbage collection (GC).
Compile code written in C++ by using the compiler command-line options as explained in Linker and compiler options.
NSJ11 provides DLLs. Therefore, you can build your own executable and link it to the JVM DLL, libjvm.so .
For more information, see invocation_api demo provided with the NSJ11 installation.
JNI applications cannot enable parallel and CMS GC if the JVM is loaded in the main thread.
Do not set signal handlers for the following signals:
SIGSEGV
SIGPIPE
SIGCHLD
SIGINT
SIGQUIT
SIGTERM
SIGHUP
SIGWINCH
SIGALRM
SIGSTK
SIGILL
SIGTIMEOUT
Set the executable to use IEEE floating-point.
NSJ11 does not support the signal-chaining facility implemented in some other vendors' JVMs.
When a program uses the Invocation API to start a JVM, its function returns parameters of type float or double that are in IEEE floating-point format.
Any parameters of type float or double that are passed to NSJ11 must be in IEEE floating-point format. If such a program requires conversion
between TNS floating-point format and IEEE floating-point format, the Guardian Procedure Calls Reference Manual documents a series of procedures with
names beginning with NSK_FLOAT_ that can be used to convert float and double data between the two formats.
To run the Invocation API demo, follow the instructions in the README file in directory
/usr/tandem/nssjava/jdk110_l11/demo/invocation_api . Directory location of invocation_api demo programs are listed in
Demonstration programs available in NSJ 11.0 .
Linker and compiler options
Subtopics
Compiler options
Linker options
Compiler options
You can use C++ code compiled using either a dialect of version 2 or version 3 for user DLLs because NSJ11 is built with a C++ version neutral flag (the —
set CPlusPlusDialect neutral option for the linker). To compile using version 2, the following compiler option must be used:
—Wversion2
—Wversion3 is the default version for TNS/E native compilers, and hence it is not needed to be defined in the compile command-line.
NSJ 11 User Guide
35
NOTE:
—Wversion4 dialect is not supported on NSJ11.
In addition, a compilation unit containing JNI code that has any floating-point parameters being passed across the JNI boundary and that is directly called by
the JVM, must use the IEEE floating-point arithmetic. IEEE floating-point format is the default for TNS/E native compilers, and hence it is not needed to be
defined in the compile command-line.
Any compilation units not called directly by the JVM can be compiled without conforming to the IEEE floating-point format. However, the complications that
can occur while using such mixed modes are beyond the scope of this manual.
The nsjjni demo shows an example of mixed modes. For information on demos, see Demonstration programs.
Linker options
IEEE floating-point is the default format for TNS/E native compilers, and hence it is not needed to be specified during linking.
How to create your own library of native code
The nsjjni demonstration program shows how to create a native library and the demo programs are listed in Demonstration programs.
Floating-point implementation
Java uses IEEE floating-point arithmetic for computation. This subsection explains the following topics:
Floating-point values
Double-precision values
Calling TNS floating-point functions from JNI code
Incompatibilities between the IEEE floating-point and TNS floating-point representations might cause loss of precision or accuracy when you convert between
TNS float or double and IEEE float or double .
NOTE:
In NSJ11, you cannot specify whether your Java classes use TNS format.
Subtopics
Floating-point values
Double-precision values
Calling TNS floating-point functions from JNI code
Floating-point values
For floating-point values, TNS floating-point representations have larger exponents (hence a larger range) than IEEE floating-point representations, but they
are less precise, which is demonstrated in the following table:
Table 1. Floating-point ranges
Floating-point representation Minimum positive decimal value Maximum decimal value
TNS
1.7272337e-77
1.1579208e77
IEEE
1.17549435E-38F
3.40282347E+38F
NSJ 11 User Guide
36
Double-precision values
For double-precision values, TNS floating-point representations have smaller exponents (hence a smaller range) than IEEE floating-point representations, but
they are more precise, which is demonstrated in the following table:
Table 1. Double-precision ranges
Floating-Point representation
Minimum positive decimal value Maximum decimal value
TNS
1.7272337110188889e-77
1.15792089237316192e77
IEEE
2.2250738585072014E-308
1.7976931348623157E+308
Calling TNS floating-point functions from JNI code
This section describes the procedure to call a TNS floating-point function from an IEEE floating-point function.
Perform the following when using TNS floating-point compiled functions in native code linked in the java executable:
Do not call the Common Runtime Environment (CRE) functions with TNS floating-point values because CRE functions are expecting IEEE floating-point
values.
Do not pass floating-point values ( float and double ) across mixed float compilation units. When passing or returning floating-point values
between IEEE floating-point compiled functions and TNS floating-point compiled functions, pass or return the following:
A double as one of the structures defined in $SYSTEM.SYSTEM.KFPCONVH ( NSK_float_ieee64 , NSK_float_tns64 ) or
/usr/include/kfpconv.h .
You can call a native function that accepts or returns a TNS float or double value if you create an intermediate function. The intermediate
function assembles between the IEEE floating-point compiled JNI method that the JVM calls and the native function that accepts or returns the float
or double value.
Either the JNI method or intermediate method can be responsible for calling one of the NSK_float_* procedures to convert between IEEE and TNS
floating-point formats.
The intermediate function:
Is compiled with TNS floating-point.
Accepts float and double arguments as one of the special structures defined in the $SYSTEM.SYSTEM.KFPCONVH or
/usr/include/kfpconv.h file.
Calls the TNS compiled native function passing TNS float or double arguments.
Converts any float or double return value to an IEEE floating-point value, which the JNI caller expects.
Returns the float or double in one of the special structures defined in the $SYSTEM.SYSTEM.KFPCONVH or /usr/include/kfpconv.h
file.
For an example, see nsjjni Demonstration programs.
Multi-threaded programming
The Java virtual machine for the NSJ11 is multi-threaded and uses POSIX User Thread (PUT) library, which conforms to the IEEE POSIX Standard 1003.1,
2004. With PUT library enabled on NonStop systems, CPU intensive thread that does not invoke an I/O, sleep, or wait can never be pre-empted by another
thread unless -XX:ThreadTimeSlice or -XX:TimeSlicePolicy option is used.
This section includes the following topics:
Thread scheduling
Threading considerations for Java code
Threading considerations for native code
NSJ 11 User Guide
37
ThreadDumpPath support
Subtopics
Thread scheduling
Threading considerations for Java code
Threading considerations for native code
Thread scheduling
When a Java thread is created, the thread inherits its priority from the parent thread. The priority of the thread varies from MIN_PRIORITY to
MAX_PRIORITY , where the default priority is NORM_PRIORITY . After a thread is created, the setPriority method can be used to alter the
priority of the thread.
Java application developers must be aware of the following consideration while designing or enabling multithreaded Java applications for Nonstop systems:
A selfish thread is a thread that executes in a tight loop without giving up control either by explicitly yielding or by initiating a blocking operation.
Since the thread-scheduling algorithm on Nonstop is nonpreemptive and does not time slice, it is possible for such a thread to prevent other threads from
getting access to CPU time. Theoretically, such a thread can run forever. However, after a while, the operating system periodically reduces the priority of
the process in stages, until its priority reaches to a lower value.
For a demonstration of scheduling on a NonStop system, review the results and output of the following programs:
Snnipet for ThreadTimeSlice feature
import java.io.*;
import java.lang.*;
class LoopThread extends Thread {
private Thread t;
private int threadNum;
private static int tick = 1;
private static volatile int numThreadsStillRunning = 0;
private static int maxThreads = -1;
private static volatile int numThreadsCreated = 0;
public
static void setMaxThreads(int num) { maxThreads = num; }
LoopThread( int num){
if ( num <= 0 || num > maxThreads ) {
System.out.println("Invalid thread number: " + num);
System.exit(1);
}
threadNum = num;
System.out.println("Creating " + threadNum );
numThreadsCreated++;
numThreadsStillRunning++;
}
public void run() {
if ( threadNum == 1 ) {
// First thread. Execute until other threads terminates
while ( numThreadsCreated < maxThreads ||
numThreadsStillRunning > 1 ) {
tick++;
}
} else {
// Sleep some time to guarantee first thread runs
try {
Thread.sleep(10);
} catch ( InterruptedException e ) {
System.out.println("Sleep interrupted.");
}
for (int i=0; i < 10000; i++ ) {
tick++;
}
NSJ 11 User Guide
38
}
System.out.println("Thread " + threadNum + " exiting.");
numThreadsStillRunning--;
}
}
public class ThreadPreemptionDemo {
public static void main(String args[])
{
int numThreadsToCreate = 2;
// LoopThread[] threads;
if ( args.length > 0 ) {
// User has specified number of threads to create
numThreadsToCreate = Integer.parseInt(args[0]);
if ( numThreadsToCreate < 2 ) {
System.out.println("Invalid argument. Minimum value = 2");
System.exit(1);
}
}
LoopThread[] threads = new LoopThread[numThreadsToCreate];
LoopThread.setMaxThreads(numThreadsToCreate);
for (int i = 0; i < numThreadsToCreate; i++) {
threads[i] = new LoopThread(i+1);
threads[i].start();
}
try {
for (int i = 0; i < numThreadsToCreate; i++) {
threads[i].join();
}
} catch (InterruptedException ex) {
System.out.println("Exception " + ex);
}
}
}
On the NonStop system, the execution of threads are not time sliced. When a thread gets a chance to run, it enters the loop and starves the other thread.
Hence, the application hangs.
Output when thread time slice is not enabled :
java -cp . ThreadPreemptionDemo
Creating 1
Creating 2
WARNING:
You will observe a hang when thread time slice option or time slice policy option is not specified. Therefore, “Creating 2” in the output may
or may not be printed.
The Java runtime supports a simple, deterministic, scheduling algorithm known as fixed-priority scheduling. The Java runtime does not time-slice. For the
NonStop system, the thread-scheduling algorithm is not preemptive; that is, a thread continues to run until it explicitly yields or otherwise causes a yield by
initiating a blocking operation on the thread. When a thread gives up control, the runnable threads of the highest priority are run in first-in-first-out order. A
lower priority thread is run (also in first-in-first-out order) only when no runnable threads of a higher priority are available.
Thread time slice
NSJ includes a JVM-forced, preemptive thread scheduling feature. This feature also provides an option to specify the time slice for threads. A thread will run
for the specified time slice, after which another thread gets dispatched from the ready queue. This helps in force-yielding a thread which consumes large
processor time so that the other ready threads also get the processor time to run.
To enable pre-emptive user threads, use the following option:
-XX:ThreadTimeSlice[=T]
Where,
T specifies the time in milliseconds (ms).
T is an optional argument.
The default value is calculated by dividing 400 ms by the number of cores on the CPU. For example, if a CPU has four cores, the default time slice value is
400 ms / 4 which is 100 ms.
NSJ 11 User Guide
39
The value of T can range between 1 to 32767.
If the specified value of T is above 32767, the value is time-sliced to 32767.
If the specified value of T is 0, the default value is used for time slice.
Following is the output for the snippet provided in Example:
Output when thread time slice is enabled
java -cp . -XX:ThreadTimeSlice=10 ThreadPreemptionDemo
Creating 1
Creating 2
Thread 2 exiting
Thread 1 exiting
Subtopics
Dynamic thread time slice policy
Dynamic thread time slice policy
Using this option, the user must specify the right value for the application. If the value chosen is large, the application can hang or loop. With the time slice
options, JVM can automatically adjust the time slice value and avoid the hang or loop. The dynamic thread time slice policy allows Java runtime to adjust the
time slice value with any of the following:
Using a fixed count value that is subtracted from the time slice value.
Using a percent value that is used to calculate by how much the time slice must be reduced.
Depending upon the number of Java threads.
Adjusting until the time slice value becomes 10 ms or user-defined minimum value.
Restoring the time slice value to the original when a blocking operation is initiated by an adjusted thread.
The policies can be used to adjust all threads or adjust only the misbehaving threads.
Subtopics
Options
Options
Subtopics
TimeSlicePolicy
ThreadTimeSliceMin
ThreadTimeSliceDecrement
ThreadTimeSlicePercent
DynamicThreadPriority
RestoreTimeSliceandPriority
TimeSlicePolicy
Syntax
-XX:TimeSlicePolicy[=PolicyStr]
Description
This option allows you to adjust the time slice policy value.
NSJ 11 User Guide
40
Parameters
PolicyStr
is the policy string. The values are keyword parameters and case-sensitive. If PolicyStr is omitted, default value is used.
NOTE:
If TimeSlicePolicy option is used, you need not specify the ThreadTimeSlice option.
PolicyStr options
Default
When a thread consumes the time slice without initiating a blocking operation, the time slice policy value is decremented by 10 ms or the user specified
-XX:ThreadTimeSliceDecrement value. The adjusted value is used for all threads.
Count
The time slice value is modified according to the number of threads. The Java runtime calculates the time slice policy value by dividing the time slice
value by the number of threads in the process. The adjusted value is used for all threads. For example, consider that the time slice value is 400 and 10
Java threads are present in a process. The calculated time slice value will be 40 ms.
NOTE:
Thrashing can result if the application has many threads.
Percent
The adjustment is done by decrementing the time slice value by 10% or the user specified -XX:ThreadTimeSlicePercent value. The value is
in the range of 1 to 50. The adjusted value is used for all threads.
PerThread
When a thread consumes the time slice without initiating a block operation, the time slice policy value is decremented by 10 msecs or a user specified
value. The adjusted value is used only for the current misbehaving thread.
PerThreadCount
Similar to Count , but applicable only to the misbehaving thread.
PerThreadPercent
Similar to Percent , but applicable only to the misbehaving thread.
ThreadTimeSliceMin
Syntax
-XX:ThreadTimeSliceMin=n
Description
This option allows you to specify a minimum value for adjusted time slice value.
Parameters
n
is a value from 10 to timeSliceValue. All TimeSlicePolicy options use this value while adjusting the time slice value. The default value is 10 ms.
NOTE:
The ThreadTimeSliceMin value converts to the next nearest multiple of 10 ms. For example, 11 ms is converted to 20 ms.
ThreadTimeSliceDecrement
Syntax
-XX:ThreadTimeSliceDecrement=n
Description
This option allows you to reduce the time slice value when a thread exceeds its time slice value. The
options use this value for adjusting the time slice value. The default value is 10 ms.
Default and PerThread TimeSlicePolicy
Parameters
NSJ 11 User Guide
41
n
is a value from 10 to timeSliceValue.
ThreadTimeSlicePercent
Syntax
-XX:ThreadTimeSlicePercent=n
Description
The value in terms of percentage that is used to reduce the time slice value when a thread exceeds its time slice value. The Percent and
PerThreadPercent TimeSlicePolicy options use this value for adjusting the time slice value. The default is 10%.
Parameters
n
is a value from 10 to 50.
DynamicThreadPriority
Syntax
-XX:+/-DynamicThreadPriority
Description
In addition to TimeSlicePolicy, NSJ provides an option to decrease the priority of a thread if it exceeds the time slice value. This behavior is similar to
Operating System reducing the priority of a process if it exceeds the time slice value. Reducing the priority of a misbehaving thread increases the chance of
running for other threads. The DynamicThreadPriority reduces the thread priority until the value reaches the minimum priority value.
The default is + , which enables dynamic thread priority and decrements the priority value of the current thread by one for every time the thread exceeds the
time slice value until the thread reaches the minimum priority value.
RestoreTimeSliceandPriority
Syntax
-XX:+/-RestoreTimeSliceandPriority
Description
Enables or disables restoration of the original time slice and/or priority. The value is used when the thread performs a blocking call like I/O or wait. The
default is + , which enables restoration.
Threading considerations for Java code
A thread-aware function blocks only the thread calling that function, rather than blocking the entire process. NSJ uses the PUT library in which all I/O are
nonblocking.
JToolkit provides a thread-aware API for performing I/O to Enscribe files, $RECEIVE , and Pathway servers by using Pathsend procedure calls. For more
information, see HPE JToolkit for NSJ Programmer's Reference .
Due to the deficit of Kernel threads, Hewlett Packard Enterprise recommends not using Fork or Join framework to gain any performance improvement on
NSJ. If you use this framework, the performance of NSJ reduces.
If you want to use Fork or Join framework and if it is used only for CPU intensive operation, Hewlett Packard Enterprise recommends that you use
-
XX:ThreadTimeSlice option to enable all threads get the CPU cycles.
NSJ 11 User Guide
42
Threading considerations for native code
NSJ supports only the POSIX User Thread library. As a result, the following issues must be considered when migrating to NSJ11:
The JNI or C/C++ code in a Java application that uses the Pthread API must be ported to use the _PUT_MODEL_ as described in the Open System
Services Programmer's Guide.
The PUT library WPUTDLL must be linked to the application.
If a user native library linked into Java creates a thread, non thread-aware operations executed in the user library might impact the operation of the Java
virtual machine. If the user library creates multiple user threads, the program needs to be more careful to ensure that the operations performed in the user
threads are thread-safe on the NonStop system. All threaded code preferably written in Java rather than native code.
You need to consider the following issues when using threads in native code linked to a Java program on a NonStop system:
NSJ uses the POSIX User Thread Library from the standard location.
Your code must include the POSIX User Thread header files in the standard location. You must use the header files from the standard location
/usr/include/ .
Creating a thread for a task does not make the task run faster.
The NonStop system does not have an implementation of native threads since threads run at a user level. Even on a multiprocessor NonStop system, all
native threads (user threads) in a process are executed in the same processor as the process. If you create user threads whose only purpose is to run a
certain task, the thread creation overhead makes the task run slower than the same task being performed without creating the thread.
The thread-scheduling algorithm is not preemptive.
A thread executes until it explicitly yields. For more information, see Thread scheduling.
In a very long-running, CPU-intensive thread, having your native code occasionally invokes the yield() method which allows timer and I/O
completions to be detected. Invocation of timer callbacks and detection of I/O completions can be severely impacted by long-running threads.
Provides standard POSIX thread API names and calling sequences which adhere to IEEE standard 1003.1, 2004. For more information, see Open System
Services Programmer's Guide.
You must be careful when using thread-aware interfaces.
The Open System Services Programmer’s Guide lists thread-aware equivalents of NonStop system-specific interfaces. These interfaces have an explicit
put_ prefix.
For example, when using a thread-aware function, do not attempt to control the set of files that are enabled for completion or directly attempt to wait for
a completion on a file registered with Pthreads ( FILE_COMPLETE_SET_ , FILE_COMPLETE_ , AWAITIO , or AWAITIOX procedure).
ThreadDumpPath support
The thread dump lists all threads in the Java process. If any of the distributed GC options are enabled, GC threads are converted into processes. Hence, the GC
threads are prefixed with * to indicate that it is a process if the application enables distributed GC.
The execution stack trace of all Java threads in a NSJ11 process can be dumped by sending a SIGQUIT signal to the Java process using the following OSS
command:
$ kill -QUIT <pid>
NOTE:
GC thread stack trace is not printed.
By default, the thread stack dump is written in text format on the stdout . NSJ11 provides the ability to redirect this output to a user-defined file using the
following Java command:
-XX:ThreadDumpPath=<path/filename>
Using the Guardian printer
NonStop Java API accepts the Guardian printer filenames.
NSJ 11 User Guide
43
The following code fragment shows how to set the Guardian printer filename and print the print.txt file:
..
String printer = "$s.#p255";
FileInputStream stream = new FileInputStream("print.txt"); // file to print
..
PrintServiceAttributeSet prAttr = new HashPrintServiceAttributeSet();
prAttr.add(new PrinterName(printer, null));
PrintServiceLookup lookup = new UnixPrintServiceLookup();
PrintService[] services = null;
..
services = lookup.getPrintServices(null, prAttr);
..
DocPrintJob job = services[0].createPrintJob();
SimpleDoc doc = new SimpleDoc(stream, DocFlavor.INPUT_STREAM.AUTOSENSE, null);
..
job.print(doc, null);
..
..
In the code fragment, $s.#p255 is the name of the configured printer. If there is no printer configured with this name, then print output is routed to
Spooler with location #p255 . To print the document, you need to explicitly reroute the document to the configured printer location. For more information,
see Spooler Utilities Reference Manual .
Dynamic saveabend file creation
NOTE:
Dynamic saveabend file creation works only with Java processes. It will not work with javahelper processes.
Dynamic saveabend file creation helps to create a saveabend file of a running Java process without aborting (abending) the Java process, and by issuing a
signal to the process. This allows the Java process to continue execution even after the abend file is created. The time taken to create the abend file, that is
the application pause time is low (measurable in ms).
The saveabend file enables you to analyze any observed Java runtime problems, such as observed high memory consumption, and low responsiveness
without impacting the running Java process.
To create a saveabend file in the working directory of the process, perform the following steps:
1. Export DUMP_CORE=1.
2. Start the Java application.
3. Press Ctrl+break while the process is running or kill -3 <PID of java application>.
Saveabend file generation
If distributed GC is enabled, the saveabend files are generated differently. The Java process or javahelper process can encounter a problem and terminate
abnormally. When one process in the Java process group terminates abnormally, the other processes detect the abnormal termination and also terminate
abnormally.
The first process that terminates abnormally dumps the entire user address space (full dump), and the other processes do the partial dump of the address
space. To analyze the problem, load the saveabend file independently in eInspect for analysis. As the partial snapshot files do not contain all the data, the
full dump must be used to obtain the data.
CAUTION:
The saveabend flag must be turned on for both Java launcher executable file and the javahelper executable file for creation of
saveabend files for both the Java and javahelper processes.
You can collect the snapshot files of the Java process and javahelper process and send it to HPE support for analysis. You must collect all the saveabend files.
Default process launch mechanism
NSJ 11 User Guide
44
Oracle provides the new -Djdk.lang.Process.launchMechanism="posix_spawn" option, to specify the mechanism to create the child
process. NSJ supports two mechanisms fork and POSIX_SPAWN . By default, POSIX_SPAWN mechanism is used to create child process. HPE
recommends you to use the standard launch mechanism provided by Oracle.
Java getLocalHost() caching
Java getLocalHost() has to make a call to the Kernel API to obtain the desired results, which is a time consuming factor. Java caches results only for
five seconds that is not useful for applications which run for a longer time.
-Dnsk.java.cachegetLocalHost=true is used to overcome the unnecessary calls made to the Kernel API, and cache the results of
getLocalHost() until the application ends.
WARNING:
Do not change the IP address of the system while running the application.
Java authentication and authorization service
Java authentication and authorization service (JAAS) is used for the following purposes:
For authentication of users, to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an
application, an applet, a bean, or a servlet.
For authorization of users to ensure they have the access control rights (permissions) required to do the actions performed.
JAAS implements a Java version of the standard Pluggable Authentication Module (PAM) framework. This plug ability permits applications to remain
independent from underlying authentication technologies. New or updated authentication technologies can be plugged in without requiring modifications to
the application. Applications enable the authentication process by instantiating a LoginContext object, which in turn references a configuration to
determine the authentication technology, or LoginModule , that is to be used in performing the authentication. The LoginModule interface provides
developers the ability to implement different kinds of authentication technologies that can be plugged in an application.
For example, one type of LoginModule might perform a username and password based form of authentication. Other LoginModules might involve
more sophisticated authentication mechanisms.
NSJ product includes LoginModule interfaces implemented by Oracle, such as JndiLoginModule and KeyStoreLoginModule , but does not
provide a LoginModule that interfaces to the Safeguard subsystem on NonStop systems. You can also develop your own LoginModule
implementation.
For more information on writing a LoginModule implementing an authentication technology, see JAASLoginModule Developer's Guide .
JavaBeans
JavaBeans are reusable software components that can run in both a design environment (inside a builder tool) and runtime environment.
The design environment is highly visual and requires that JavaBeans provide design information to the programmer and to customize its behavior and
appearance.
In the runtime environment, JavaBeans might be visible in the case of a Graphical User Interface (GUI), or invisible in the case of a data feed control.
Because of the CLI nature of the NonStop operating system, NSJ11 supports only runtime execution of invisible JavaBeans. The NSJ11 does not support
design-time execution or runtime execution that requires a GUI operation. In NSJ11, the Boolean expression java.beans.Beans isGuiAvailable
returns the value false .
For more information about JavaBeans, see Oracle JavaBeans document .
Dejavu fonts
Dejavu fonts are packaged as part of the NSJ11 at <install-folder>/lib/fonts/ instead of Lucida fonts. The corresponding font configuration
files ( fontconfig.bfc and fontconfig.properties.src ) are updated.
NSJ 11 User Guide
45
OpenJDK does not provide fonts and relies on underlying platform fonts. For NSJ on OpenJDK, Dejavu fonts are provided at JDKHOME/lib/fonts .
Multiple fonts are provided, the number might vary based on the font configuration file fontconfig.properties/fontconfig.bfc .
The list of fonts that are provided are as follows:
DejaVuMathTeXGyre.ttf
DejaVuSansMono-BoldOblique.ttf
DejaVuSans-Bold.ttf
DejaVuSansMono-Oblique.ttf
DejaVuSans-BoldOblique.ttf
DejaVuSansMono.ttf
DejaVuSans-ExtraLight.ttf
DejaVuSerif-Bold.ttf
DejaVuSans-Oblique.ttf
DejaVuSerif-BoldItalic.ttf
DejaVuSans.ttf
DejaVuSerif-Italic.ttf
DejaVuSansCondensed-Bold.ttf
DejaVuSerif.ttf
DejaVuSansCondensed-BoldOblique.ttf
DejaVuSerifCondensed-Bold.ttf
DejaVuSansCondensed-Oblique.ttf
DejaVuSerifCondensed-BoldItalic.ttf
DejaVuSansCondensed.ttf
DejaVuSerifCondensed-Italic.ttf
DejaVuSansMono-Bold.ttf
DejaVuSerifCondensed.ttf
The following two files are updated accordingly to support Dejavu fonts:
fontconfig.bfc
fontconfig.properties.src
Debugging Java programs
This subsection discusses the debugger architecture and how to run the programs involved in debugging Java applications, and also discusses the following
topics:
Debugging overview
Transports
Java command-line options to run a debuggee
Starting the Java debugger (JDB) tool
Debugging JNI code
Debugging Java and JNI code
Subtopics
Debugging overview
NSJ 11 User Guide
46
Transports
Java command-line options to run a debuggee
Starting the Java debugger (JDB) tool
Debugging JNI code
Debugging Java and JNI code
Debugging overview
NSJ11 supports Java Platform Debugger Architecture (JPDA) that provides debugging support for the Java platform. For more information, see Oracle's Java
Platform Debugger Architecture Documentation.
NSJ11 ships a terminal oriented non-GUI debugging tool. This Java Debugger Tool (JDB) can be used on a NonStop system to debug the Java applications
running on the same NonStop system, or on another NonStop system, or any other platform.
You can also use the non-GUI debugging JDB and other vendors' GUI debuggers running on Microsoft Windows and other platforms to debug NSJ11
applications running on a NonStop system.
Transports
A JPDA transport is a form of inter-process communication used by a debugger application and the debuggee. NSJ11 provides a socket transport that uses
the standard TCP/IP sockets to communicate between the debugger and debuggee.
By default, NSJ11 uses socket transport. NSJ11 does not support shared memory transport.
Java command-line options to run a debuggee
For remote debugging, you need to start the Java application to be debugged (debuggee) as a server using the following command:
java -Xdebug -Xnoagent
-agentlib:jdwp=transport
-Xdebug
Enables debugging.
-Xnoagent
Disables the old Sun.tools.debug agent. This is the default value.
-agentlib:jdwp=sub-options
sub-options are specified in the following format:
name1[=value1],name2=[=value2]...
The sub-options are as follows:
transport
Indicates the name of the transport. The value is dt_socket , and by default, NSJ11 uses dt_socket .
server=y
y means listen for a debugger application
address = transport-address-for-this-connection
The transport address is the port number in which the debuggee is listening for the debugger or a range of port value from which the debuggee selects
the first available port to listen for the debugger. The following syntax is used:
address=[<name>:]<port> | <start port>-<end port>
where,
<name> is the host name.
<port> is the socket port number.
NSJ 11 User Guide
47
<start port> is the starting port number for a range of ports.
<end port> is the ending port number for a range of ports.
suspend=y suspends the debuggee just before the main class loads.
Optionally, you can specify the -Xint argument, by using only the interpreter and not the HotSpot compiler.
NOTE:
Specifying a range of port numbers for address is specific to NonStop.
The subsequent examples show the various ways in which the connection address is specified:
When the port number is specified
java -Xdebug -Xnoagent
-agentlib:jdwp=transport=dt_socket,server=y,address=4000,
suspend=y classname arguments
When the range of ports are specified and hostname is implicit
java -Xdebug -Xnoagent
-agentlib:jdwp=transport=dt_socket,server=y,address=4000-4050,
suspend=y classname arguments
When the machine name and port range are specified
java -Xdebug -Xnoagent
-agentlib:jdwp=transport=dt_socket,server=y,address=someMachine:4000-4050,
suspend=y classname arguments
Starting the Java debugger (JDB) tool
The Java Debugger ( JDB ) tool can be started so that it communicates with the debuggee by using the jdb command as described for the following
situations:
If you are using JDB on the same NonStop system where the debuggee runs, use the following command:
jdb -attach portnum
If you are using JDB on a different NonStop system from where the debuggee runs, use the following command:
jdb -attach host-name:portnum
If you are using JDB from Microsoft Windows or any other platform, use the following command:
jdb -connect com.sun.jdi.SocketAttach:hostname=hostname,port=portnum
Additional information
If you are using a GUI debugger, refer to the vendors' documentation to configure the debugger to communicate with the debuggee.
Remote debugging of NSJ applications can be performed using NSDEE debugger tool. For more information, see NonStop Development Environment for
Eclipse User Guide.
For more details on command-line options, see Connection and Invocation Details
Debugging JNI code
Use the inspect debugger tool available on the NonStop system to debug the native code. This native code is written by application developer, and is used
with the Java program. Use NonStop Development Environment for Eclipse (NSDEE) or Native Inspect to debug the native code. For more information, see
NonStop Development Environment for Eclipse User Guide and Native Inspect Manual.
You can use the following command to start java in an inspect debugger:
run -debug java java_options
NSJ 11 User Guide
48
To debug native code, wait until the DLL is loaded. Native Inspect allows you to stop the program after the DLL is loaded so that you can set breakpoints. For
information on how to set the breakpoints, see Native Inspect Manual.
You can view and debug the native routine to be debugged and other native routines that routine calls. All other scopes above the native routine are either
compiled or interpreted Java code, which the inspect debugger has no knowledge about.
To add an even breakpoint on DLL open event, use the NSDEE debugger. For more information, see Breakpoints section in the NonStop Development
Environment for Eclipse User Guide.
Debugging Java and JNI code
You can use the Native Inspect debugger tool to debug the native code and Java Debugger tool to debug the Java code simultaneously. You need to start the
Java debuggee process in a debugger.
For example, type the following command:
run -debug java -Xdebug -Xnoagent -agentlib:jdwp=sub-options
You can then use the Java Debugger tool to communicate with the debuggee process as explained in Debugging overview.
Deviations in JVM specification options
The compiler specification options for both the java and jdb tools deviate from standard Java because NSJ11 implements only the HotSpot server VM
and does not implement a client VM. Accordingly, the options that specify running the client VM are not valid.
Subtopics
java: Java application launcher command-line option deviations
jdb: Java debugger command-line option deviations
java: Java application launcher command-line option deviations
-client
Selects the Java HotSpot Client virtual machine (VM).
NOTE:
The -client option is not valid with NSJ11.
-server
Selects the Java HotSpot Server virtual machine (VM).
NOTE:
The -server is the default option for NSJ11. Hence, specifying -server is optional.
For more information about the java tool and additional deviations from standard Java, see Implementation of garbage collector types and java in the
NSJ11 Tools Reference Pages .
jdb: Java debugger command-line option deviations
-tclient
Runs the application in the Java HotSpot client VM.
NOTE:
The -tclient option is not valid with NSJ11.
NSJ 11 User Guide
49
-tserver
Runs the application in the Java HotSpot server VM.
NOTE:
The -tserver is the default option for NSJ11. Hence, specifying -tserver is optional.
For more information about jdb and how to start a Java program so that jdb can attach to it, see jdb in the NSJ11 Tools Reference Pages .
Garbage collection (GC)
This section discusses the following implementation-specific topics about garbage collection for NSJ:
General information on garbage collection
Heap Layout
Managing generation size
Implementation of garbage collector types
Subtopics
General information on garbage collection
Heap Layout
Managing generation size
Implementation of garbage collector types
General information on garbage collection
In general, the various GC algorithms, and modeling in NSJ are same as those implemented by Oracle in their JVM. Accordingly, you must refer to the Java web
site for details about garbage collection. However, some of the information is not applicable to NSJ. For more relevant information, see Java SE HotSpot
Virtual Machine Garbage Collection Tuning.
Heap Layout
The subsequent sections provide an overview about heap layouts managed in Parallel and CMS GC.
NOTE: CMS GC is deprecated in NSJ11.
Subtopics
Heap layout for Parallel and CMS GC
Heap layout for Parallel and CMS GC
In NSJ, the memory is managed in generations (or memory pools) based on objects at different ages for Java objects. The following figure illustrates the heap
layout for generations.
Figure 1. Layout for generations
NSJ 11 User Guide
50
NOTE:
In the illustration, the metaspace is shown as a contiguous space. Actually, it consists of one or more blocks whose address may not be
contiguous.
The following list describes the various generations:
Young (also called new) generation
The JVM allocates objects in the young generation pool. Minor garbage collection happens when this young generation is full and the JVM is unable to
allocate new objects. The young generation also includes two survivor spaces. One survivor space is empty at any time and serves as a destination for
the next GC operation, and which also copies the collection of any live objects in the Eden and other survivor space. Objects are copied between survivor
spaces in this way until they are old enough to be tenured - copied to the tenured generation.
Tenured (also called old) generation
The JVM moves objects that survived minor garbage collections from the young generation to the old generation.
Metaspace generation
Class objects and metadata objects are allocated in the metaspace generation. However, metaspace is allocated from the JVM heap.
The young and tenured generations each have an area called RESERVED , which is allocated at the initialization and is used when garbage collection does
not have sufficient space to satisfy the allocation request. In the Oracle implementation, the address range for reserved area is reserved but memory space is
not allocated until it is used. Whereas, in NSJ, the address range for reserved area is reserved and memory space is allocated during the initialization.
Managing generation size
Several java command options allow you to manage the initial size and maximum size of the combined young and tenured generations.
-Xms
sets the initial size for the combined young and tenured generation. The default initial size is 1024 MB. Smaller values lead to shorter but more
frequent garbage collections, whereas larger values lead to longer but less frequent garbage collections. For large server applications, Hewlett Packard
Enterprise recommends that the initial size must be equal to the -Xmx .
specifies the maximum size of the memory allocation pool in bytes. This value must be a multiple of 1024 and greater than 8 MB. If you specify less than
16 MB, heap size is set automatically to 16 MB. The default value is 1 GB.
You must consider the amount of physical memory available on the system while choosing a value for -Xmx . If the virtual memory of a process
exceeds the physical memory, then memory thrashing occurs and the application performance slows down.
Hewlett Packard Enterprise recommends that the application specifies the same value for -Xms and -Xmx . If only -Xmx is specified in the
command-line, the default value used for -Xms is the same value that is specified for -Xmx .
When the Java heap size is specified using the Java options [-XX:MaxHeapSize, -XX:InitialHeapSize , -Xms , and -Xmx ] , JVM
aligns the specified value to 8 MB.
The virtual space of a process must not exceed the size of the physical memory. If the physical memory size is 32 GB, the maximum Java heap size is
NSJ 11 User Guide
51
around 28 GB (2 GB for JVM memory requirement, and 2 GB for C heap, thread stack, and 28 GB for Java heap).
-XX:MetaspaceSize=<n>
Where <n> is an initial size of the metaspace. The default metaspace size is 20.7 MB.
-XX:MaxMetaspaceSize=<n>
Where <n> is an maximum size of the metaspace. By default, there is no limit on the metaspace size and is limited by the available virtual memory.
-XX:MaxMetaspaceExpansion=<n>
Where <n> is the maximum metaspace expansion size. By default, the metaspace is expanded by a maximum value of 5312 KB.
Implementation of garbage collector types
The available garbage collectors in NSJ are as follows:
Serial collector (default collector for young and tenured generations)
Parallel collector
Parallel compacting collector
Concurrent Mark-Sweep collector (or Concurrent low-pause collector)
WARNING:
When PUT_PROTECTED_STACK_DISABLE is set, the behavior of all implementation of Garbage Collector types is undefined except
Serial Collector.
Table 1. Summary of garbage collector implementations
Collector Type
Implementation Status
Serial collector
Default collector for the young and tenured generation
Parallel collector
Allowed
Concurrent Low-Pause collector Allowed
Subtopics
Parallel collector
Concurrent Low-Pause collector
G1GC collector
Handling large GC log files
Parallel collector
The parallel collector (or throughput collector) uses the parallel version of the young generation collector.
NOTE:
To enable the appropriate GC, use the "+" option. To disable the appropriate GC, use the "—" option.
The following are the valid java command options, that specify or apply to a parallel collector:
-XX:+UseParallelGC
This option enables parallel scavenge for the young generation.
NOTE:
The default GC is the serial GC.
-XX:+UseParallelOldGC
This option enables parallel GC for the old generation. This option automatically enables parallel scavenge (for young generation).
NSJ 11 User Guide
52
-XX:+UseAdaptiveSizePolicy
This option enables adaptive size policy for the Java heap. By default, this option is disabled in NSJ. However, if the parallel GC is enabled, this option is
enabled automatically unless it is disabled it in the command-line.
NOTE:
AdaptiveSizePolicy on NSJ considers only the throughput and pause time goal. The footprint goal is not considered.
-XX:+AggressiveHeap
Obtains the platform resources and configures the heap layout accordingly, uses parallel collector, and enables AdaptiveSizePolicy option. XX:+AggressiveHeap option is not supported in NSJ. However, if you specify this option the JVM exits with the error:
—XX:+AggressiveHeap option is not supported on this platform.
-XX:MaxGCPauseMillis
Sets a value for a desired pause time. The default value is 200 milliseconds.
–XX:ParallelGCThreads=<n>
This option is used to specify the number of parallel GC threads for the parallel garbage collection. The default number of GC threads created is equal
to the number of cores present in the processor. If a value greater than the number of cores is specified, the following warning is displayed and the
application continues to run:
WARNING:
Parallel GC thread count ( <n> ) cannot be greater than the number of cores ( <numcore> ) in a CPU. Using <numcore> for
Parallel GC count.
Concurrent Low-Pause collector
A concurrent low-pause collector can be selected for tenured generation. This collector does most of the collection concurrently with the application
execution. This collector divides the collection in different phases and operates specific phases concurrently with the application execution, and others in
stop the world mode.
The following java command options that specify a concurrent low-pause collector are valid for NSJ:
-XX:+UseConcMarkSweepGC
This option enables concurrent mark sweep GC for the old generation. Note that the default GC is the serial GC for old generation, and hence this option
must be specified to enable concurrent mark sweep GC. By default, if this is selected, UseParNewGC is selected for the young generation. The CMS
garbage collector is deprecated.
UseParNewGC is used with -XX:+UseConcMarkSweepGC , since this option is deprecated, UseParNewGC option and its uses are also
deprecated.
G1GC collector
Oracle command line options support G1GC. The options are as follows:
-XX:+UseG1GC
This option enables G1GC. G1GC is supported on NSJ 11. JVM does not exit with it.
-XX:ConcGCThreads=<n>
This option specifies the number of threads that are to be used for concurrent phase of the garbage collector.
Handling large GC log files
Oracle command line options support GC log file rotation. The options are as follows:
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=<num_of_files>
-XX:GCLogFileSize=<logsize>
NSJ 11 User Guide
53
NOTE:
-Xverbosegc supports the listed options.
HPE’s GC log rotation option, -XX:GCLogLimits , remains unchanged and supports both -Xloggc and -Xverbosegc options.
NOTE:
HPE’s LogRotation option -XX:GCLogLimits=M,N overrides Javasoft’s LogRotation options. If HPE's -XX:GCLogLimits is
specified, GC logs rotate to new log file after N records.
Memory management considerations
This section provides information about memory management considerations for JDK 11.0.
Subtopics
JVM data segment for NSJ11
Java heap size with NSJ11
Native heap size with NSJ11
JVM data segment for NSJ11
NSJ11 allocates one extensible flat segment for its internal dynamic memory requirement. The initial size of this segment is 512 MB, and the maximum size is
12 GB. This segment is referred as JVM data segment.
NOTE:
The metaspace is allocated from JVM data segments.
When the allocated portion of the segment is filled, and if the allocated size of the segment has not reached the maximum value of 12 GB, then the segment is
resized by increasing its size by multiples of 512 MB. To avoid segment resize during the application runtime NSJ provides an option
InitialJVMHeapSize , that can be used to specify the maximum JVM heap size required by the application. If this option is specified during JVM
initialization, the JVM heap segment is resized with the value specified and it avoids the resize of the JVM heap segment later when the application runs. It
must be noted that the value specified with the command line option is a suggestive value. If the application needs more virtual memory, the segment can be
resized until it reaches 12 GB. The syntax for this option is as follows:
–XX:InitialJVMHeapSize=<size>
where, size can vary from 512 MB to 12 GB. Default value of InitialJVMHeapSize is 512 MB.
Sample Invocation:
java –XX:InitialJVMHeapSize=4G <className>
In the sample command invocation, during JVM initialization, the JVM Heap segment is resized to 4 GB.
NOTE:
Minimum size of the JVM heap segment cannot be less than 512 MB.
Java heap size with NSJ11
The default initial and maximum Java heap size for NSJ is 1 GB. The theoretical maximum value of Java heap that can be specified is 484 GB. However, the
actual maximum Java heap size is limited by the available Kernel-managed swap space.
Native heap size with NSJ11
The native heap size is limited to 12 GB. Java does not have command-line option to modify the value of the native heap size. If application requires more than
12 GB native heap size, then it can be modified by using the xld -change heap_max option on Java launcher program.
NSJ 11 User Guide
54
Java garbage collector tuning for application performance
NSJ incorporates the HotSpot VM. This section discusses the options available for tuning the JVM, suggests flags and values to tune the Java HotSpot VM,
and points to the HotSpot tuning information on the Internet. GC tuning is assisted by GC profile data which can be collected and analyzed as explained in the
subsequent sections.
Since GC occurs when generations fill up, the amount of available total heap memory has direct impact on the performance. The parameters that affect the
heap are as follows:
-Xms
The startup size of memory allocation pool (the Java heap).
-Xmx
The maximum memory allocation pool.
When using NSJ11, the theoretical maximum value is 484 GB. However, the actual limit is constrained by the size of physical memory and swap space available
from the Kernel-managed swap space, and the number of processes contending for these resources. For more information, see Java heap size with NSJ11 .
For larger server applications, the default values of the two options listed are usually inadequate. In general, you must assign as much memory to the JVM.
Another important factor that affects performance is the proportion of the heap that is assigned to the young generation. The parameters for the young
generation heap are as follows:
-XX:NewRatio=nn
The ratio between the young and old.
-XX:NewSize=nn
The lower size bound.
-XX:MaxNewSize=nn
The upper size bound.
-XX:SurvivorRatio=nn
Tune the survivor spaces.
For example,
java -Xms512m -Xmx512m -XX:NewSize=256m -XX:MaxNewSize=256m \ -XX:SurvivorRatio=2 <class>
These options notify the JVM to set:
The initial size of the heap to 512 MB.
The maximum heap size to 512 MB.
The new generation to 256 MB (128 MB belongs to Eden and 2x64 MB survivor).
The old generation to 256 MB.
For more information about all these parameters, see Java HotSpot VM Options .
For more information about tuning garbage collection with the Java SE 8 HotSpot virtual machine, and for general performance tuning information, see the
following documentation:
HotSpot Virtual Machine Garbage Collection Tuning Guide.
The article Tuning Java I/O Performance .
Java Performance Documentation .
NOTE:
The following options do not apply for NonStop system:
-XX:-UseBoundThreads
-XX:+UseAltSigs
-XX:+AllowUserSignalHandlers
-XX:+MaxFDLimit
-XX:-UseLWPSynchronization
-XX:PreBlockSpin=nn
-XX:-UseMPSS
-XX:+UseSpinning
NSJ 11 User Guide
55
javahelper
The javahelper is an executable file that is launched by JVM to run GC threads and compiler thread as a process. The Java helper process is a multithreaded application. It interacts with Java application using the standard NonStop Kernel IPC mechanism. The Java helper processes are launched on the
same processor on which the Java process is running.
The maximum number of parallel Java helper processes is equal to the number of cores in the processor. If CMS GC is enabled, the number of
processes created is equal to the number of cores. Additionally, there is one CMS GC task process. These processes are unnamed processes.
ParNewGC
Java helper processes are bound to separate IPUs for improved performance. The IPU number to which a Java helper process is bound is the ordinal number
of that Java helper process. For example, if parallel GC is enabled on a 4-core CPU, 4 Java helper processes are launched. The first Java helper process created
binds to IPU 0, second to IPU 1, third to IPU 2, and fourth to IPU 3.
The compiler process is bound to the IPU whose number is one higher than the IPU number in which the Java process is running. If the Java process is running
on the highest numbered IPU, the compiler process runs on the lowest available IPU.
You must not initiate javahelper executable file directly, and if it is initiated directly, the process displays the error message:
Internal Error: Cannot invoke directly!!!
In NSJ, when the non-serial GC is enabled using command line option, one process is launched for each GC thread. The Java and corresponding javahelper
processes are called as process group and they perform the following:
Run on a same logical processor.
Run simultaneously on different IPU(s) of the same processor.
Provide a single process image to the Java application.
Share the virtual address space.
Communicate among themselves using Guardian IPC mechanism.
Subtopics
Unhandled exception
Unhandled exception
If Distributed Garbage Collector (DGC) is enabled and a Java or its javahelper processes encounter unhandled exception, the process which encounters the
exception terminates. The other processes in the process group detect the termination of the process and exit abnormally.
Java process name
A Java process can be started as a named process by specifying -name option with the run command. In NSJ11, there is a restriction in starting a named
Java process and it is explained in the following subsections.
Subtopics
Using JDK
Using JDK
A Java application can be launched with NSJ11 using the following method:
$ export PATH=/usr/tandem/nssjava/jdk110_l11/bin/:$PATH
$ run –name /G/JAVA1/ java HelloWorld
NSJ 11 User Guide
56
GC profiling
NSJ supports an HPE proprietary option, -Xverbosegc to capture the Java application's GC activity. The output of this option can be used to view and
analyze the detailed statistics in an offline mode with NSjmeter . The following -Xverbosegc option generates detailed information about the spaces
within the Java heap before and after garbage collection:
-Xverbosegc[:help]|[0|1][:file=[stdout|stderr|<filename>]]
Fore more information on the syntax options of -Xverbosegc , see java in the NSJ11Tools Reference Pages.
For more information on application profiling, see Application tuning and profiling.
Subtopics
GC log rotation
-XX:+HeapDump and _JAVA_HEAPDUMP environment variable
GC log rotation
When GC logging is enabled using the -Xverbosegc or -Xloggc option, by default, the GC data is written to a single log file of unlimited size. NSJ
allows you to control the size and number of the GC log files. The GC log records are written in the specified number of GC log files in a round-robin method.
This allows GC data to be archived easily and thus helps to limit the amount of disk space consumed by the GC log files. Log rotation is also supported when
using zero-preparation -Xverbosegc .
To enable log rotation, use the following option along with -Xverbosegc , -Xloggc , or zero-preparation verbosegc :
-XX:GCLogLimits=M,N
M
is a non-negative integer that specifies the number of rotating GC log records per file. A value of 0 specifies unlimited number of GC log records per file.
NOTE:
Each GC log record corresponds to a GC event.
N
is a non-negative integer that specifies the maximum number of rotating GC log files. A value of 0 specifies unlimited number of files.
You must use both M and N when you use the -XX:GCLogLimits=M,N option. If this option is not specified, the default behavior is to write a single
GC log file with unlimited size.
When rotation is in effect, a sequence number is appended to the GC filename (0 through N-1). For example, filename.0 , filename.1 , and
filename.2 .
With log rotation, when the specified maximum number of files (N) is reached, logging cycles back to the first file in the sequence
overwriting the old GC data with new data. If the maximum number of files (N) is never reached, then no log rotation occurs.
(filename.0) , thereby
GC log rotation example
To rotate between two log files, each with a maximum of 100,000 GC records, use the following command:
-XX:GCLogLimits=100000,2
To maintain an unlimited number of smaller files, each with a maximum of 1,000 GC records, use the following command:
-XX:GCLogLimits=1000,0
-XX:+HeapDump and _JAVA_HEAPDUMP environment variable
The -XX:+HeapDump option can be used to examine memory allocation in a running Java application by taking snapshots of the heap over time.
Another way to get heap dumps is to use the _JAVA_HEAPDUMP environment variable, setting this environment variable enables you to take memory
snapshots without making any modifications to the Java command-line. To enable this functionality, either use the command-line option or set the
environment variable before starting the Java application.
For example, export _JAVA_HEAPDUMP=1
With the -XX:+HeapDump option enabled, each time the process is sent a SIGQUIT signal, the JVM produces a snapshot of the Java heap in
ASCII format:
hprof
NSJ 11 User Guide
57
java_<pid>_<date>_<time>_heapDump.hprof.txt.
If you set the _JAVA_HEAPDUMP_ONLY option, heap dumps are triggered by SIGWINCH instead of SIGQUIT. Only the heap dump is produced, that is, the
thread and trace dump of the application to STDOUT is suppressed. Setting the _JAVA_BINARY_HEAPDUMP environment variable along with
_JAVA_HEAPDUMP_ONLY produces a binary format heap dump instead of ASCII, the SIGWINCH is sent to the process.
NOTE:
Before producing the heap dump, JVM performs a full GC.
Subtopics
Other HeapDump options
Using heap dumps to monitor memory usage
Other HeapDump options
In addition to -XX:+HeapDump , the following three different HeapDump options are available:
-XX:+HeapDumpOnCtrlBreak
-XX:+HeapDumpOnOutOfMemoryError
-XX:+HeapDumpOnly
Table 1. HeapDump options
Option
-XX:+HeapDump
Trigger
Format
SIGQUIT
ASCII
Filename
java_<pid>_<date>_<time>_heapDump.hprof.txt
Set the
_JAVA_BINARY_HEAPDUMP
environment variable to obtain
binary
SIGQUIT
Binary
java_<pid>.hprof.<millitime>
Out of
XX:+HeapDumpOnOutOfMemoryError Memory
Binary
java_<pid>.hprof
-XX:+HeapDumpOnCtrlBreak
or the file specified by
-XX:HeapDumpPath=file
-XX:+HeapDumpOnly
SIGWINCH ASCII
java_<pid>_<date>_<time>_heapDump.hprof.txt
Set the
_JAVA_BINARY_HEAPDUMP
environment variable to get
binary
-XX:+HeapDumpOnCtrlBreak
It enables taking snapshots of the Java heap when a SIGQUIT signal is sent to the Java process, without using the JVMTI-based Xrunhprof:heap=dump option. This option is similar to the -XX:+HeapDump option, except the output format, which is in binary hprof
format and the output is placed in a filename with the naming convention java_<pid>.hprof.<millitime> .
If the environment variable _JAVA_HEAPDUMP is set, and the -XX:+HeapDumpOnCtrlBreak option is specified, both hprof ASCII and
binary dump files are created when a SIGQUIT is sent to the process.
For example, the following files are created:
java_27298.hprof.1152743593943
java_27298_060712_153313_heapDump.hprof.txt
If JAVA_BINARY_HEAPDUMP is set, and the -Xrunhprof:heap=dump command is run, both hprof ASCII and binary files are produced
for this option.
-XX:+HeapDumpOnOutOfMemoryError
It enables dumping the Java heap when the Java process encounters a java.lang.OutOfMemoryError exception. The heap dump filename
defaults to java_pid<pid>.hprof in the current working directory. The option -XX:HeapDumpPath=file can be used to specify the
heap dump filename or a directory where the heap dump file must be created. The only heap dump format generated by the XX:+HeapDumpOnOutOfMemoryError option is the hprof binary format.
NSJ 11 User Guide
58
NOTE:
The -XX:+HeapDumpOnOutOfMemoryError option does not work with the low-pause collector (option XX:+UseConcMarkSweepGC ).
-XX:+HeapDumpOnly
It enables heap dumps using the SIGWINCH signal (signal 12) with the help of -XX:+HeapDumpOnly option or _JAVA_HEAPDUMP_ONLY
environment variable. This interface is provided to separate the generation of thread and trace information triggered through SIGQUIT from the heap
dump information. If the -XX:+HeapDumpOnly option is specified or _JAVA_HEAPDUMP_ONLY environment variable is set, the heap dump
functionality is triggered by sending SIGWINCH to the process. The printing of thread and trace information to STDOUT is suppressed.
The heap dump is written to a file in the following format:
java_<pid>_<date>_<time>_heapDump.hprof.txt.
The default output format is ASCII. The output format can be changed to hprof binary format by setting _JAVA_BINARY_HEAPDUMP
environment variable. This environment variable can also be used with the -XX:+HeapDump option to generate hprof binary format with
SIGQUIT signal.
Using heap dumps to monitor memory usage
By creating a series of heap dump snapshots, you can see how the number and size of objects varies over time. It is a good idea to collect at least three
snapshots. The first one serves as a baseline. It must be taken after the application has finished initializing and has run for a short period.
The second snapshot is taken after the residual heap size has grown significantly. You can monitor the residual heap size by using
NSjmeter .
—Xverbosegc and
Take the last snapshot just before the heap has grown to a point where it causes problems resulting in the application spending the majority of its time doing
full GCs. If you take other snapshots, spread them out evenly based on residual heap size throughout the running of the application. The leak is easier to track
down if the difference in size between heap dumps is large.
After collecting snapshots, view them in NSjmeter , and perform the following:
Compare the files using File>Compare .
You must be able to find out the type of objects that are accumulating in the Java heap.
Select a type of objects by using Mark to Find .
Go back and view one of the snapshots.
Go to Metric>Call Graph Tree and do a Find . You must be able to see the context of the object retention.
TIP:
When creating heap dumps, running the application with smaller heap sizes results in smaller heap dump files. Smaller heap dump files
enable NSjmeter analysis to use lesser memory.
Large heap support
The following is the example which invokes an application with 24 GB of Java heap size:
JAVA_HOME pointing to JDK
java –Xms24G –Xmx24G <other command-line options> <application>
NOTE:
The virtual space of a process must not exceed the size of the physical memory. If the physical memory size is 32 GB, the maximum Java
heap size is around 28 GB (2 GB for JVM memory requirement, and 2 GB for C heap, thread stack, and 28 GB for Java heap).
Posting signals to javahelper process
You can post signals to a Java application. In NSJ, if non-serial GC such as parallel and CMS GC (deprecated in NSJ11) is enabled, javahelper processes are
created to perform the garbage collection. The javahelper process installs signal handlers for the synchronous signals and blocks the asynchronous signals.
NSJ 11 User Guide
59
Hence, posting asynchronous signals to javahelper process is not affected. When a synchronous signal occurs, the javahelper process signal handler creates
an error log file and closes.
NOTE:
Java process continues to process the synchronous and asynchronous signals.
Java signal handlers
A Java program installs signal handlers for the signals that the current application interacts with. However, there is one restriction for an application when it
installs handler for the signals. The restriction is that the application cannot install handlers for the signals that are used by the Java Virtual Machine
(reserved signals). If the application attempts to install handlers for the reserved signals, java.lang.IllegalArgumentException is thrown.
There are two types of reserved signals for which a user cannot install handlers:
1. Signals for which the user cannot install handlers always.
2. Signals for which the user can install handlers, if the application does not enable specific command line options.
The following table provides information about the reserved signals for which signal handlers cannot be installed, and also about the reserved signals which
can be installed by enabling or disabling some options from command line.
Table 1. Reserved Signals List
Reserved Signals (Always)
Reserved Signals (depending upon command line options) 1
SIGFPE
SIGWINCH
SIGILL
SIGALRM
SIGSEGV
SIGUSR2
SIGQUIT
SIGHUP
SIGUSR1
SIGINT
SIGSTK
SIGTERM
SIGCHLD
1
Click the specific signal to obtain information about how to install signal handlers for the corresponding signals.
SIGWINCH
HeapDumpOnly feature uses SIGWINCH signal. Hence, the application installs signal handler for this signal, provided HeapDumpOnly option is
disabled.
HeapDumpOnly option is either enabled by using XX:+HeapDumpOnly Java command line option or by setting 1 for the environment variable
( _JAVA_HEAPDUMP_ONLY ).
NOTE:
By default, HeapDumpOnly option is false, hence, the application can install signal handler if it does not explicitly enable
HeapDumpOnly option.
SIGALRM
Zero preparation verbose garbage collection feature uses SIGALRM signal. By default, ZeroPrepVerboseGC is enabled.
ZeroPrepVerboseGC must be disabled to use SIGALARM for other purposes.
To disable ZeroPrepVerboseGC , use the following JVM option:
-XX:-ZeroPrepVerboseGC
SIGUSR2
Zero preparation profiling feature (HPE specific feature) uses this signal. The profiling can be enabled or disabled for the entire runtime of the
application or for a selected duration. The details are as follows:
If -Xeprof::off is specified in the Java command line, the zero preparation profiling feature is disabled for the entire duration for which the
application runs, and hence the application can install signal handler for SIGUSR2 signal.
If -Xeprof is specified in the Java command line, the zero preparation profiling feature is enabled for the entire duration for which the
application runs, and hence the application cannot install signal handler for SIGUSR2 signal.
An alternate signal for zero preparation profiling feature can be specified by using:
NSJ 11 User Guide
60
Xeprof:time_on=<SIGUSR1|SIGUSR>,time_slice=<SIGUSR1|SIGUSR2> .
If SIGUSR2 is not specified as the signal for zero profiling feature, then application can install signal handler for SIGUSR2.
SIGHUP
JVM uses this signal to support shut down hook if -Xrs is not specified in the command line option (reduce signal usage). If –Xrs is specified in
the command line option, the application can install signal handlers for SIGHUP signal.
SIGINT
JVM uses this signal to support shut down hook if -Xrs is not specified in the command line option (reduce signal usage). If –Xrs is specified in
the command line option, the application can install signal handlers for SIGINT signal.
SIGTERM
JVM uses this signal to support shut down hook if -Xrs is not specified in the command line option (reduce signal usage). If –Xrs is specified in
the command line option, the application can install signal handlers for SIGTERM signal.
Error file
When a fatal error occurs, one or more error log file is created depending upon the type of GC used by the application.
If the application uses Serial GC and a fatal error occurs, only one error file is created and it is in the form hs_err_pid<pid>.log
where,
<pid> is the process ID of the Java process. This is the same format of the error file created in earlier version of NSJ.
If the application uses non-serial GC and a fatal error occurs, more than one fatal error files are created and their filename format is of the form
hs_err_pid<Java pid>_<Java pid | javahelper pid>.log
where,
<Java pid> is the process ID of the Java process and <javahelper pid> is the process ID of the javahelper process.
The first process ID is always the Java process ID. The second process ID is the process ID of the process that creates the error file. If the error file is created
by the Java process, the second process ID is the Java process ID and if created by the javahelper process, it is the javahelper process ID. The number of error
files created is equal to the number of processes in the Java process group.
When a fatal error occurs, the process that encounters the fatal error closes. The header of the error log file generated by this process contains information
about the fatal error. This could be an OS signal or a JVM internal error. If Parallel or Concurrent GC is used, other processes in the Java process group also
close and create error log files as mentioned earlier. The error log file contains additional information about the process that encountered the fatal error and
the list of processes that forms the Java group.
Thus, the process that encountered the fatal error can be identified by looking at the headers of all the error log files generated.
Examples
The following is the first few lines of the error log file when a Java process with parallel or concurrent GC closes abnormally:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=7ed16ab4, pid=1979711505, tid=10 # # JRE version: 7.0 # Java VM: Java HotSpot(TM)
Server VM (21.1-b02-svcnedccadmin:2012jul25-11:47 mixed mode nsk oss-ia64 ) # Problematic frame:
# C
[(DLL libjvm.so)+0x0]
invoke__17PSParallelCompactSFb + 0x1C0 (DLL libjvm.so)+0x0 #
This example indicates that the hs_err_pid1979711505_1979711505.log file was created by a Java process with PID 1979711505, and that
it closed due to SIGSEGV.
The following is the first few lines of the error log file when a javahelper process closed after detecting the abnormal termination of another process in the
Java process group:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#
Internal Error (0xe0000010), pid=2097152069, tid=4 #
Error: Process 3,1140 in the Java process group has
terminated abnormally. Initiating termination of all the other processes in the process group # # JRE
version: 7.0 # Java VM: Java HotSpot(TM) Server VM (21.1-b02-svcnedccadmin:2012jul25-11:47 mixed mode nsk
oss-ia64 ) # Failed to write core dump.
#
#
#
Please report this error to HPE customer support.
----------- P R O C E S S
G R O U P-------------
NSJ 11 User Guide
61
# The processes in the Java process group are:
# PID (CPU, PIN):
# 620757051 (3,1138)
# 1006633021 (3,1141)
# 2097152069 (3,1139)
# 1291845689 (3,1144)
# 1979711505 (3,1140)
This example indicates that javahelper process with PID 2097152069 created the file hs_err_pid1979711505_2097152069.log . The log
indicates that the javahelper process had closed due to another process in the Java process group closing abnormally. The Java PID corresponding to this
javahelper process is 1979711505. There are four javahelper processes in the Java group and their PIDs are 620757051, 1006633021, 2097152069,
and 1291845689.
Subtopics
ErrorFile with %p option
ErrorFile with %p option
The product flag —XX:ErrorFile=file can be used to specify where the error log file is created.
Where, file represents the full path for the file location. The file variable can contain the substring %p .
If the application uses Serial GC and a fatal error occurs, the substring %p is expanded to process ID of the Java process.
If the application uses Parallel or CMS GC and a fatal error occurs, the substring %p is expanded to <Java pid>_<[Java pid| javahelper
pid]> .
Where, <Java pid> is the process ID of the Java process ID and <javahelper pid> is the process ID of the javahelper process.
The first process ID is always the Java process ID. The second process ID is the process ID of the process that creates the error file. If the error file is created
by the Java process, the second process ID is the Java process ID and if created by the javahelper process, it is the javahelper process ID. The number of error
files created is equal to the number of processes in the Java process group. This is illustrated by the following examples:
When the filename is specified as errorlog%p
java –XX:ErrorFile=errorLog%p SampleJava
where, errorLog is the filename of the error file.
If DGC is enabled, multiple files are created with the name format:
errorLog<Java pid>_<[Java pid| javahelper pid]>
where,
<Java pid>
is the Java process ID
<javahelper pid>
is the process ID of the javahelper process
For error log file created by the Java process, both PIDs are Java process ID and for error log file created by the javahelper processes, the first one is the Java
process ID and the second one is the javahelper process ID.
When the filename is specified as error%p.log
java –XX:ErrorFile=error%p.log SampleJava
where, error.log the filename of the error file.
If DGC is enabled, multiple files are created with the name format:
error<Java pid>_<[Java pid| javahelper pid]>.log
where,
<Java pid>
is the Java process ID
<javahelper pid>
is the process ID of the javahelper process
For error log file created by the Java process, both PIDs are Java process ID and for error log file created by the javahelper processes, the first one is the Java
NSJ 11 User Guide
62
process ID and the second one is the javahelper process ID.
System property
The system property sun.arch.data.model is available in NSJ and provides information on the data model used. It returns the value "64" for NSJ11.
The system property os.arch will return amd64 for Java process.
LogVMOutput option
If the -XX:+LogVMOutput option is used, the output produced by JVM is redirected to the ./hotspot.log file or file specified in –
XX:LogFile=<file> option. If any of the DGC options are specified in the command-line, the file contains the output produced by the Java process
alone. However, the output produced by the javahelper processes are not logged to this file.
SecureRandom startup enhancement
When this option (precisely, java.security.nativeRNG ) is enabled, it reduces the processing time taken to generate the first random number in a
Java application.
By default, this option is not enabled. Use the following option to enable the same:
—Djava.security.nativeRNG=true
VirtualMachine.list() support
The list method returns a list of Java process running on the NonStop system. Following are the changes in output compared to other platforms:
The name of the Java process is the binary name for applications using Invocation API.
For pure Java application, the name of the Java process is the class name or the
jar name available in the command line.
Usage of —XX:+PerfDisableSharedMem or —XX:-UsePerfData is ignored on NonStop.
Change in loading of .hotspot_compiler and .hotspotrc files
The default implicit loading of the .hotspot_compiler and .hotspotrc files from the current working directory is changed. These files are no longer loaded by
default. For existing deployments that rely on .hotspot_compiler (for example, to exclude a method from hotspot compilation), and .hotspotrc, an unsupported
behavioral option is provided to simulate the old loading behavior. The following command line options support old behavior:
-XX:Flags=.hotspotrc
reverts to old behavior for .hotspotrc.
-XX:CompileCommandFile=.hotspot_compiler
reverts to old behavior for the .hotspot_compiler.
Precompilation enhancement
Syntax
NSJ provides an option to compile Java methods on first invocation instead of compiling the method after the invocation count reaches the hotspot count. A
new advanced compile command compilealso is used to implement this feature. The methods that must be precompiled can be specified in advanced
compile command-line option or in advanced compile command file.
NSJ 11 User Guide
63
CompileAlsoProfile allows you to create the compilealso command file. When CompileAlsoProfile option is provided, the methods
that are hotspot compiled are written to the profile file with the prefix compilealso . The generated file can be directly specified in the advanced compile
command file option.
You need ensure that the number of methods for precompilation is limited, so that profile file is collected appropriately. If the profile collection window is
huge, it is likely that large number of methods get hotspot compiled and the profile file contains lot of entries. Also, all methods get precompiled and affects
the application startup or warmup time.
–XX:CompileAlsoProfile=<filename>
Description
This option enables you to create a file containing a list of methods that are hotspot compiled during the application execution. Each hotspot compiled
method is written to the output file after prefixing the method with compilealso keyword. The generated file can be directly used to specify the
methods to be precompiled using compilealso option. The application is first run using this option to create the compile command file, and the created
file is used by CompileCommandFile option. The creation of the compile command file is automated, which enables compilealso command to execute in
ease.
You can execute the compilealso command:
Using command line through -XX:CompileCommand option.
Using compile command file, which is generated by profiling option CompileAlsoProfile through -XX:CompileCommandFile .
Syntax of CompileAlsoProfile command with %p option
–XX:CompileAlsoProfile=<fileNamePrefix>%p<fileNameSuffix>
%p
Is replaced with OSS PID of the Java process.
Syntax of CompileAlsoProfile command with %n option
–XX:CompileAlsoProfile=<fileNamePrefix>%n<filenameSuffix>
%n
Is replaced with process name for a named process or with _<cpu>_<pin> for an unnamed process.
<cpu>
Is the string representation of the CPU number. <cpu> is of two characters and prefixed with "0".
<pin>
Is the string representation of the PIN number. <pin> is of five characters and prefixed with "0".
If no method got hotspot compiled, then the output file is not created. If the generated file exists in the folder,
filename for CompileAlso%p.log , where %p is the PID.
compilealso will fallback and generate a
Examples
With %p option
This example creates a file named compilealso_721420613.log , where, 721420613 is PID of the current process.
-XX:CompileAlsoProfile=CompileAlso%p.log
With %n option
This example creates a file named compilealso_TEST.log , where the current process is a named process and the process name is $TEST .
-XX:CompileAlsoProfile=CompileAlso%n.log
This example creates a file named compilealso_03_00453.log , where the current process PIN is 3,453.
-XX:CompileAlsoProfile=CompileAlso%n.log
With combination of %p and %n option
This example shows that CompileAlsoProfile also accepts any combination of %p and %n option.
-XX:CompileAlsoProfile=Prefix%p%p.log generates Prefix_1409286693_1409286693.log XX:CompileAlsoProfile=Prefix%n%n.log generates Prefix_00_05638_00_05638.log XX:CompileAlsoProfile=Prefix%n%p.log generates Prefix_00_05815_738197608.log XX:CompileAlsoProfile=Prefix%p%n.log generates Prefix_134218212_00_06790.log
run -name=/G/mlog with -XX:CompileAlsoProfile=Prefix%n%n.log generates Prefix_MLOG_MLOG.log run -name=/G/mlog
with -XX:CompileAlsoProfile=Prefix%n%p.log generates Prefix_MLOG_855638120.log run -name=/G/mlog with -
NSJ 11 User Guide
64
XX:CompileAlsoProfile=Prefix%p%n.log generates Prefix_905969768_MLOG.log
Subtopics
Using command line
Using CompileCommandFile command
Using command line
Syntax
-XX:CompileCommand=command,method
Description
This command is used to specify the compilealso command and the method to be precompiled on the command line.
Example
-XX:CompileCommand=compilealso,java/lang/String.indexOf
This example command compiles the indexof method of the String class on first invocation.
Using CompileCommandFile command
Syntax
-XX:CompileCommandFile=<filename>
Description
This command allows you to specify several methods and command specified by a file. Each line in the command file represents a command, class name, and
method name for which the command is used. Each line in the file contains a hotspot compiler advanced command and the name of the method including the
class name. For compilealso advanced compiler command, the file generated by –XX:CompileAlsoProfile option can be specified. With this,
the methods that have to be precompiled are specified using compilealso command.
For more information about CompileCommandFile , see the Oracle Java documentation .
Parameters
filename
is the name of the file containing the JIT compiler commands.
Restrictions
Do not specify both CompileAlsoProfile and CompileCommand/CompileCommandFile options.
The file generated by CompileAlsoProfile option is used by CompileCommandFile option. Hewlett Packard Enterprise recommends you to
execute these commands independently. First with the CompileAlsoProfile option to generate a file containing hotspot methods prefixed with
compilealso command. The generated file is then used with CompileCommandFile to compile these methods in advance. This enhances the
performance by avoiding executing of these methods in an interpreter mode.
Example
To precompile toString() method of String class, the following entry is added to the command file.
compilealso java/lang/String::toString
UseCompilerProcess option
Syntax
–XX:+UseCompilerProcess
NSJ 11 User Guide
65
Description
This option enables the compiler thread to run as a separate process (similar to GC threads) on the same CPU as the Java process. The compiler process
bounds to an IPU, that is different than on which the Java process is running.
Usage
When hotspot compiler process is enabled with –XX:+UseCompilerProcess option:
The hotspot compilation output commands like -XX:+PrintCompilation and –XX:+LogCompilation are disabled. Also, these options do
not print compilation-related logs on the STDOUT.
Specifying the compilation output command like –XX:+PrintCompilation or –XX:+LogCompilation displays a warning message
indicating that the print or log compilation option is ignored and the execution continues.
WARNING:
Printing and logging of hotspot compilation cannot be combined with -XX:+UseCompilerProcess .
Specifying number of compiler processes
This compiler process supports only one compiler process (thread) per Java process. The number of compiler processes can be specified by using the following
syntax.
-XX:CICompilerCount=<n>
where, <n> specifies the number of compiler processes.
If -XX:+UseCompilerProcess is specified, the default value and the maximum value of the compiler process for the
else the default value is 2.
CICompilerCount is 1,
If -XX:+UseCompilerProcess is specified and the compiler process value is greater than 1 then the compiler process value is modified to 1 and
the following warning message is displayed:
WARNING:
Number of compiler threads cannot be set to more than 1 when -XX:+UseCompilerProcess option is used. Proceeding with
Compiler thread Count = 1.
BackgroundCompilation with UseCompilerProcess
BackgroundCompilation is enabled when an hotspot compiler process is enabled with -XX:+UseCompilerProcess option.
To disable BackgroundCompilation , you need to explicitly mention -XX:-BackgroundCompilation on the command line.
MOVBE Option
The x86 CPU is a little-endian system and NonStop is a big-endian system. The JVM generates instructions to convert the data from little-endian to bigendian before storing the data to memory. The JVM converts the data from big-endian to little-endian after loading the data from memory to register for
dynamically generated code.
The JVM dynamically generated code for load and store emit BSWAP and MOV instructions. As the source and target are in memory and BSWAP works only
on registers, JVM must have temporary registers for BSWAP instruction to work. As number of registers are less on x86 compared to Itanium, using BSWAP
leads to save/restore temporary registers, impacting application performance. To improve the performance, by default, MOVBE instruction will be used when
the processor support is available.
To disable using MOVBE, use the following:
-XX:-UseMOVBE
If you enable MOVBE on a processor that does not support MOVBE instruction, JVM prints the following warning:
Java HotSpot(TM) Server VM warning: MOVBE instruction is not available on this CPU
Process Timer Granularity Option
Syntax
-XX:+UseFineTimerGranularity
NSJ 11 User Guide
66
Description
This command enables high-resolution timers for applications to use. The high-resolution timer gives access to a fine grained counter source for applications.
When this option is enabled, the minimum timeout value is 32 microseconds. The default timeout value is 1 ms.
Error Messages
If this option is enabled on HPE Virtualized Converged NonStop, the following warning message is displayed:
Java HotSpot(TM) Server VM warning: Could not enable FineTimerGranularity option. Disabling
FineTimerGranularity option
If this option is used in J-Series, the following error message is displayed:
Unrecognized VM option 'UseFineTimerGranularity'.
NOTE:
This option is not supported on Virtualized Converged NonStop Systems.
Usage
The timer granularity feature can be used in the Java LockSupport class that is java.util.concurrent.LockSupport . This class provides a
method parkNanos() to verify if the current thread is allowed to run, if not, wait for an appropriate timeout value which is specified in ns. Despite,
parkNanos() accepting wait time in ns, NonStop Kernel converts it to a nearest ms. Therefore, applications are restricted to contain with a ms wait time.
If the timer granularity feature is enabled, NonStop Kernel converts the specified timeout value to multiple of 32 microseconds.
Example
import java.util.concurrent.locks.LockSupport;
public class TestTimerGranularity {
public static void main(String args[]) {
int waitTime = 32000; // 32 micro seconds is the minimum value
int
loopCount = 10;
long actualWaitTime;
long averageWaitTime;
// Variable to hold start/end time for each iteration
long startTime[] = new long[loopCount];
long endTime[] = new long[loopCount];
// To enable System.nanoTime and lockSupport.parkNanos to be loaded
// invoke them before entering the loop
actualWaitTime = System.nanoTime();
LockSupport.parkNanos(waitTime);
for (int i = 0; i < loopCount; i++) {
startTime[i] = System.nanoTime();
LockSupport.parkNanos(waitTime);
endTime[i] = System.nanoTime();
}
for (int i = 0; i < loopCount; i++ ) {
actualWaitTime = (endTime[i] - startTime[i] ) / 1000;
System.out.println("Wait duration for " + (i+1) + " iteration = " +
actualWaitTime);
}
}
}
If the Java program is compiled and run using java -cp . -XX:+UseFineTimerGranularity TestTimerGranularity , the following
output is displayed with a timeout value nearing around 127 microseconds. The timeout value is higher than 32 microseconds is due to the execution of the
other logic due to various latencies including process scheduling and also processor busy time.
Wait duration for 1 iteration = 123
Wait duration for 2 iteration = 127
Wait duration for 3 iteration = 126
Wait duration for 4 iteration = 128
Wait duration for 5 iteration = 126
Wait duration for 6 iteration = 127
Wait duration for 7 iteration = 127
Wait duration for 8 iteration = 127
Wait duration for 9 iteration = 127
Wait duration for 10 iteration = 127
If the Java program is compiled and run without using -XX:+UseFineTimerGranularity ( java -cp . TestTimerGranularity ), the
following output is displayed with a timeout value of more than 1000 microseconds.
NSJ 11 User Guide
67
Wait duration for 1 iteration = 1017
Wait duration for 2 iteration = 1044
Wait duration for 3 iteration = 1002
Wait duration for 4 iteration = 1031
Wait duration for 5 iteration = 1020
Wait duration for 6 iteration = 1018
Wait duration for 7 iteration = 1023
Wait duration for 8 iteration = 1023
Wait duration for 9 iteration = 1026
Wait duration for 10 iteration = 1021
NOTE:
Fine granularity applies only to time intervals specified in microseconds, as opposed to centiseconds.
Java print service
The Java Print Service (JPS) implemented in NSJ11 uses the headless version of the javax.print API. JPS allows you to print on printers directly to NonStop
systems and to network printers attached to a local area network (LAN) or wide area network (WAN). For information on configuring network printers, see
Spooler FASTP Network Print Processes Manual . For information on the Spooler subsystem, see Spooler Utilities Reference Manual .
All printing features and attributes in the JPS classes listed below work when the NonStop spooler and printer support the API. However, the NonStop
operating system requirement for sending text and postscript files to separate printers also applies when printing in JPS. The following are the JPS classes:
javax.print
javax.print.attribute
javax.print.attribute.standard
javax.print.event
For applications using the java.awt.print.PrinterJob class, the printer must be postscript enabled. For information on enabling postscript
printing, see Spooler FASTP Network Print Processes Manual .
Transactions
NSJ11 allows you work with transactions in the following ways:
Use the Current class methods to define transactions across transaction services, such as transactions that include JDBC calls.
Use the NonStop TMF which is a transaction manager used on NonStop. For more information on implementing and using JTA, see JTA Implementation
on NonStop section in the NonStop Middleware Tools for Java Reference Manual .
This section explains the following topics:
Controlling maximum concurrent transactions
Current class methods
If you use JNI and transactions, see Java native interface (JNI) . When you use JNI, the information available in Controlling maximum concurrent transactions
applies.
Subtopics
Controlling maximum concurrent transactions
Current class methods
Controlling maximum concurrent transactions
NSJ11 application processes, by default, can start a maximum of 200 concurrent transactions in each process. By setting the
JAVA_PTHREAD_MAX_TRANSACTIONS environment variable, you can control the maximum number of TMF transactions allowed per process to less
than 1000. The following is the syntax to set the maximum transactions allowed per process:
NSJ 11 User Guide
68
JAVA_PTHREAD_MAX_TRANSACTIONS environment variable
Specifies the maximum number of TMF transactions allowed per process.
Permissible values are 100 through 1000. The default value of 200 is used when the variable is:
Not set.
Set to a value less than 100 or to a value greater than 1000.
For example, to specify 200 transactions per process, use the following command:
export JAVA_PTHREAD_MAX_TRANSACTIONS=200
Current class methods
The Current class is based on version 0.5 of the Java Transaction Services (JTS) specification.
Table 1. Current Class methods
Method
Description
begin
Starts a new transaction and associates it with the calling thread.
commit
Commits the transaction associated with the calling thread.
get_control
Gets a
Control
object representing the transaction associated with the calling thread.
get_status
Gets the status of the transaction associated with the calling thread.
get_transaction_name
Gets a descriptive name of the transaction associated with the calling thread.
resume
Sets or resumes association of a transaction with the calling thread.
rollback
Rolls back the transaction associated with the calling thread.
rollback_only
Marks the transaction associated with the calling thread so that the only possible outcome is to roll
back the transaction.
set_timeout
Modifies the time-out value associated with transactions started by subsequent invocations of the
begin
method.
suspend
Suspends the association of the calling thread with a transaction context.
The following code fragment shows how to use the begin() and commit() methods of the Current class:
import com.tandem.tmf.Current;
Current tx = new Current();
// start a new transaction in the current thread
tx.begin();
// ... access Pathway server
// commit current transaction (JDBC and Pathway)
tx.commit(true);
For more information on the Current class, see com.tandem.tmf package description in the HPE JToolkit for NSJ Programmer's Reference .
Application tuning and profiling
NSJ 11 User Guide
69
This chapter provides information about application tuning and profiling, and it includes the following topics:
Profiling application performance
Tuning application performance
Subtopics
Profiling application performance
Tuning application performance
Profiling application performance
Application profiling and monitoring are supported through NSjmeter tool, which works in combination with NSJ option -Xeprof .
NSjmeter tool contains support for both 32-bit and 64-bit NSJ 8.0, and NSJ11.
The NSjmeter console is a GUI tool that runs on Java platforms that support GUI, such as HP-UX, Linux, and Windows. It is used to perform the following
profiling activities:
Monitoring live Java applications. For more information, see NSjmeter User’s guide.
Analyzing garbage collection data.
Analyzing profiling data.
Subtopics
Collecting profile data for analysis
Obtaining garbage collection data for analysis
Other profiling options
Collecting profile data for analysis
There are three ways to collect profile data for offline analysis using the NSjmeter console:
1. To enable eprof profiler, start the Java application with -Xeprof option.
2. Zero-preparation profiling, start, and stop the profile data collection by sending signal to the running Java application. (This uses the
Xeprof profiler,
internally, to profile the application dynamically).
For more information on analyzing profile data and the instructions to use NSjmeter tool, see NSjmeter User’s guide.
Subtopics
-Xeprof
Zero preparation profiling
-Xeprof
The -Xeprof option generates profile data for NSjmeter . -Xeprof focuses primarily on performance problems that characterize large server
applications. It collects method clock and CPU times, method call count and call graph, and lock contention statistics.
This option creates profile data file with a file extension .eprof . This file can be opened in the NSjmeter console and the collected metrics can be
viewed.
For more information on this option, see NSJ11 Tools Reference Pages .
NSJ 11 User Guide
70
Zero preparation profiling
Profiling can be started from the command line by sending a signal to the Java process indicating JVM to start eprof . Engaging zero preparation profiling
may have a short term impact on application performance as the JVM adjusts to the demands of performing dynamic measurements.
To collect profiling data without interrupting your application, perform the following from the command line:
1. Confirm that no -Xeprof option has been specified on the command-line.
2. Find the process ID of the running Java application.
3. Start the profiling interval - send a signal to the JVM by typing the following command:
kill –USR2 pid
The following message is displayed:
eprof: starting profiling
Allow the profiling to continue for a desired length of time.
4. Stop the profiling interval by sending the same signal to the JVM:
kill -USR2 pid
The following message is displayed:
eprof: terminating profiling
writing profile data to ./filename.eprof
5. You can now open the saved file in the NSjmeter console and view the collected metrics.
Obtaining garbage collection data for analysis
Garbage collection data can be collected in either one of the following two ways:
1. Data collection with -Xverbosegc .
Launch the Java application using the –Xverbosegc option. For more information on the option, see NSJ11 Tools Reference Pages.
2. Data collection with Zero preparation.
Data collection can be started from the command line by sending a signal to the Java process to indicate JVM to start GC data collection.
To collect GC data without interrupting an already running application, perform the following from the command line:
a. Confirm that -Xverbosegc or -Xloggc option is not specified.
b. Locate the process ID of the running Java application.
c. Start the profiling interval. Send a signal to the JVM by entering the following command:
kill -ALRM pid or kill -14 pid
The GC data is written to a file named java_pid.vgc in the current directory of the JVM process.
Allow the profiling to continue for a required length of time.
d. Stop the data collection interval by sending the same signal to the JVM:
kill -ALRM pid
e. You can now open the saved file in the NSjmeter console and view the collected metrics.
After completing the data file collection, perform the following steps:
1. Transfer the data file to an NSjmeter console compatible platform (HP-UX, Windows, or Linux).
2. Run the NSjmeter console and open the data file.
NSJ supports rotational GC logging in multiple GC log files to help control the GC log file size. For information on GC log rotation, see GC log rotation.
For information on analyzing GC profile data and instructions to use NSjmeter tool, see NSjmeter User’s guide.
NSJ 11 User Guide
71
Other profiling options
TACL command status can be used to obtain the detailed status of application, including the process time of a Java process. Also, PSTATE tool can be
used to get details about the Java process.
In NSJ, if Parallel or CMS GC (deprecated in NSJ11) is enabled, a Java application consists of a Java process group that includes the Java process and
javahelper processes. If parallel or CMS GC is enabled, run the TACL command status and PSTATE/PSTATE2 tool individually for the Java and the javahelper
processes. To obtain all the javahelper processes for a Java process, nsjps can be invoked with -gc option. For information about nsjps , see NSJ11
Tools Reference Pages.
Also, the C heap usage reported by PSTATE tool for an application running with NSJ11 will be lesser than C heap usage reported when the same application is
run with NSJ6. This is because most of the JVM allocations and the Java heap are moved to flat segments in NSJ 8.0 and later versions.
Tuning application performance
Subtopics
Determining the heap size setting
Determining the heap size setting
You must set the Java heap to a value appropriate for your application for optimal performance. This section discusses the guidelines for setting the heap
size.
To study the frequency and length of the JVM garbage collection operation, use the -verbose:gc (-Xverbosegc) option in the JVM arguments.
Then use this data to tune the heap usage of the JVM based on your application requirements.
NOTE:
JVM allocates the maximum Java heap at start-up. Hence, the swap space considerations for the JVM process are the maximum Java heap
space specified and other JVM memory requirements and the memory requirements for all native components.
To identify the swap usage of a process or the swap requirements for a CPU, use the NSKCOM utility.
For example, to identify the swap usage of all the processes or a particular process, enter the following commands at the OSS prompt:
$ gtacl –p nskcom
NSKCOM - T5838L01 BASE (15OCT20) - Sep 2 2020
(c) Copyright 1995-2020 Hewlett Packard Enterprise Development LP
$SYSTEM.SYSTEM.ZSYSCFG
KMS.SWAPFILE = 0 $DATA03.SWAP.CPU0A STOP
KMS.SWAPFILE = 0 $DATA03.SWAP.CPU0B STOP
.
.
.
KMS.SWAPFILE = 5 $SWAP45.SWAP4.CPU05
NSK-status swap-usage 1,525 ,detail
SYSTEM : \SYSTEM1 LOGTIME : June 26, 2012 13:57:14
TYPE : (E=Extensible S=Shared)
(CPU Page size is 16384 Bytes)
Following is the output for the preceded commands:
Process
Pri
User-ID
Program File Name
1,525
1
200,13
$JAVDV01.ZYQ00003.Z000Q3GF
KMSF-BACKED SEGMENTS: (Process Space Guarantee =
-- )
-----------------------------------------------------------------------------
NSJ 11 User Guide
72
SEG-ID TYPE
SIZE
KBYTE
RESERVATION
PAGES
KBYTE
----------------------------------------------------------------------------Heap+Global+SRL+Stack
1068
69 MB
16
1917
1
29 MB
16
1069
64 MB
16384
64 MB
1065
1067
64 MB
1088 MB
4096
69636
64 MB
1088 MB
2100
8B
1
16
2101
8B
1
16
-----------------------------------------------------------------------------TOTAL
92034
1246 MB
FILE-BACKED SEGMENTS: None
______________________________________________________________________________
NSK-
In the preceding output, the JVM process uses 1246 MB of swap space and has six segments allocated. The JVM process was started with a heap size of 1024
MB, which shows that apart from the Java heap, the process requires about 222 MB of process-specific and application-specific data.
NOTE:
To get an applicable sample of the swap usage for a particular JVM process, check this swap usage at steady state, where all the native
components used by the JVM are fully initialized and running.
For related tuning guides, see Tuning Guide for iTP Secure WebServer and NonStop Servlets for JavaServer Pages (NSJSP) on HPE
NonStop Servers.
Migrating applications
This section provides the following:
Information about migrating from NSJ 8 to NSJ 11.
The changes required to migrate applications that use earlier versions of NSJ.
The various terminologies are as follows:
NSJ 7 is the product based on Java SE JDK 1.7.x
NSJ 8 is the product based on Java SE JDK 1.8.x
NSJ11 is the product based on Java SE JDK 11.0.x
Subtopics
Summary of migration changes
Summary of migration changes
Table 1. Summary of migration changes for NSJ versions
Migration Topic
NSJ 7.0 32-bit
NSJ 7.0 64-bit
NSJ 8.0 32-bit
NSJ 8.0 64-bit
Installation changes
Applicable
Applicable
Applicable
Applicable
N/A
N/A
N/A
Java based JAR file locations N/A
For information about earlier Java version changes, see release notes at the Oracle Java web site for the particular version of Java. For information about
changes in NSJ11, see Supported and unsupported features of NSJ11 .
For more information about JDK migration considerations from JDK 8.0 to JDK 11.0, see Oracle JDK Migration Guide .
Subtopics
Installation changes
NSJ 11 User Guide
73
Java based JAR file locations
Installation changes
For information on Installing NSJ11, see Installing NSJ11.
Java based JAR file locations
NOTE:
If JAR files are still used in the directory /usr/tandem/java/jre/lib/ext , NSJ11 does not honor as JAR based file locations are
not supported.
NSJ Specific Tools
Subtopics
nsjps
-Xeprof
—Xverbosegc
-Xverbosegc:help for NSJ 11
nsjps
NOTE: nsjps is the replacement tool for the jps tool.
The nsjps tool is a process status tool that lists and monitors the Java processes running on a system.
Subtopics
Synopsis
Synopsis
nsjps [ <options> ]
The following options are supported:
NSJ 11 User Guide
74
Option
Purpose
-cpu <cpuNumber>
Lists the Java processes running on the specified CPU.
-user <userId|userName>
Lists the Java processes owned by specified user.
-heap { < | = | > } <size {K|M|G|k|m|g} >
Lists the Java processes with matching heap.
-parent <pid>
Lists the children of the specified Java process.
-h
Displays the current heap size.
-l
Displays Java or Java helper processes in long format.
-v
Includes argument in the display.
-p
Includes the Guardian pin in the output.
-u
Includes the owner in the output.
-t
Displays the process and elapsed time.
-help
Prints the nsjps help text.
-count <cnt>
Repeats the listing of Java or GC process for the specified number of times.
-delay <time>
Specifies the time (in seconds) to sleep before the next sample.
-pid <pid>
Lists the Java process specified by <pid> .
-jh
Lists the Java and javahelper (GC and compiler) processes.
-cp
Lists the Java and compiler processes.
-gc
Lists the garbage collector processes
-gc <pid>
Lists the Java process corresponding to the GC process.
-x
Provides cross reference of parent and child Java processes.
Input Options
The input option is used to initiate the nsjps tool with various options to select the Java process based on the selection criteria.
-gc
In NSJ 11, Parallel GC and Concurrent Mark Sweep GC (CMS GC) are enabled. To use the multicore capabilities of NonStop platform, the parallel and
CMS GCs are run as a separate process in the same processor where the Java process is running. Because of this, in NSJ 11, a Java application consists
of a Java process, and one or more GC processes (if parallel or CMS GC is enabled).
By default, nsjps lists only the Java process.
A process is a Java process if it is using libjvm.so file. For example, in the following output, rmid and tnameserv are listed as a Java
process even though they use a different binary.
PID
Cmd
268435474
java
67108888
rmid
33554457
100663323
tnameserv
java
NSJ 11 provides the -gc input option to obtain details about GC processes. If -gc option is specified, GC process details are printed with the
corresponding Java process. If -gc is not specified, the heap size and process time are consolidated values for the Java and corresponding GC
processes.
The following example shows the usage and sample output for -gc option:
nsjps -gc
PID
Cmd
NSJ 11 User Guide
75
45676
java
67894
javahelper
-gcpid <pid>
To obtain details about the Java process corresponding to a GC process, -gcpid <pid> is provided, where, <pid> refers to the <pid> of the
GC process.
The following example shows the usage and sample output for -gcpid option:
nsjps -gcpid 67894
PID
Cmd
45676
java
Do not use -gcpid with the following options:
-pid
-cpu
-user
-heap
-parent
-x
-cpu <cpuNumber>
This option lists the Java processes running on the CPU specified by the cpuNumber . The following example shows the usage and output for -cpu
option:
nsjps -cpu 1
PID
Cmd
50331674
java
-user <UserID | username>
This option lists the Java process run by the user specified by userID or userName . The following example shows the usage and output for user option:
nsjps -user nsjava.guest
PID
Cmd
50331674
java
-pid <pid>
This option lists the Java process specified by <pid> . This option can be used with the other existing options of nsjps . Do not use -pid option
with the following options:
-gcpid
-cpu
-user
-heap
-parent
-x
If -pid option is used with these options, the following error statement is displayed and the command exits:
-pid option cannot be used with -gcpid/-cpu/-user/-heap/-parent/-x options
-jh
This option lists all the javahelper processes and it is inclusive of both GC processes and compiler processes.
Do not use this option with the following options:
-cp
-gc
If -jh is used with these options, the following error statement is displayed and the command exits:
NSJ 11 User Guide
76
-jh option cannot be used with -gc/-cp options
-cp
This option lists all the compiler processes and does not include GC processes.
Specifying Heap Size
The -heap option lists the Java processes which match the specified heap size. This option accepts heap sizes in kilobyte and megabyte by suffixing the
value with K or M (the suffix character is not case-sensitive). In a 64–bit JVM, the heap sizes are large, therefore, the heap size can be suffixed with G
(indicates that value is in Gigabyte). The following example shows the usage and output for -heap option:
nsjps -heap \> 1G
PID
Cmd
79289
45678
java
java
-parent <pid>
This option lists the child process of the given process ID of the Java process. The following example shows the usage and output for -parent
option:
nsjps -parent 16777243
PID
754974740
Cmd
java
Cross Reference Option
NSJPS provides -x option that prints the parent-child Java process relationships. This helps to identify the child Java processes started by a particular
parent process. In the cross reference listing, only the Java processes are considered and not the GC processes. The following example shows the usage and
output for -x option.
nsjps -x
PID
743899154
ParentPID
911671351
Cmd
java
89587743
1062666314
java
Child processes for parent 911671351
743899154
Child processes for parent 1062666314
89587743
Output Options
The output options are used to print details such as, PIN, User ID, and process ID on the selected Java processes.
Heap sizes
NSJPS prints the heap size only in bytes. Therefore, even if the heap size is large, for example 24 GB, NSJPS displays it as 25,769,803,776 bytes. With
NSJ, the heap spaces required for JVM and Java heap are allocated from flat segments and the size output of a Java or GC process includes the size of these
segments and the native C-heap. The following example shows the usage and output for -h option:
/home/daya/ACC/nssjava/jdk110_l11/bin/nsjps -h
PID
16777243
Cmd
java
Heap
377126912
-h option
If —h option is used with —gc option, then the heap size for each process in the Java process group is listed separately. The following example shows
the usage and output for -h option:
nsjps -h -gc
PID
251658247
Cmd
java
Heap
1963311104
67108872
javahelper
278528
33554441
16777226
javahelper
javahelper
278528
278528
-l option
This option lists the Java or GC process command in long format. The following example shows the usage and output for -l option:
NSJ 11 User Guide
77
nsjps -l
PID
Full Path
1040187405
/usr/tandem/nssjava/jdk110_l11/bin/java
-v option
This option lists the argument passed to the Java process. The following example shows the usage and output for -v option:
nsjps -v
PID
Cmd
arguments
989855920
java
-XX:+UseParallelGC HelloWorld
-p option
This option lists the Guardian pin of the Java or GC process. The following example shows the usage and output for -p option:
nsjps -p
PID
989855920
Cmd
java
PIN
1,1173
922747051
java
1,390
-u option
This option lists the Java process and the owner of this Java or GC process. The following example shows the usage and output for -u option:
nsjps —u
PID
989855920
Cmd
java
User
SUPER.SUPER
922747051
javahelper
SUPER.SUPER
-t option
This option displays the process and elapsed time of a Java Process. If —gc option is specified then the time specified is separate for Java and GC
process. Otherwise, the time is a consolidated output time of Java and GC process. The following example shows the usage and output for -t option:
nsjps —t
PID
Cmd
CpuTime
ElapseTime
1895825444
java
0:00:23.346
0:33:10.325
PID
989855920
Cmd
java
CpuTime
0:26:28.543
ElapseTime
2:01:17.923
922747051
javahelper
0:00:01.085
2:01:05.844
1090519214
javahelper
0:00:00.799
2:01:05.594
nsjps —t —gc
-count <cnt> option
This option repeats the listing of Java process specified by number in <cnt> . The following example shows the usage and output for -count
option:
nsjps -count 2 -delay 1
PID
Cmd
1895825444
1040187405
java
java
1895825444
1040187405
java
java
-delay <time> option
This option lists the Java process listing after specified delay <time> . The following example shows the usage and output for -delay option:
nsjps -count 2 -delay 1
PID
1895825444
Cmd
java
1040187405
java
1895825444
java
1040187405
java
Help Command output
NSJ 11 User Guide
78
The help command reflects the command-line options and they are listed in Synopsis.
-Xeprof
The —Xeprof option generates profile data for NSjmeter. The —Xeprof option controls profiling of Java applications running on JRE for NonStop OS for
the Java 2 Platform and collects method clock and CPU times, method call count, and call graph. (For more information on NSjmeter, see NonStop NSjmeter
5.0 User's Guide).
NOTE:
Zero preparation profiling is started from the command line by sending a signal to the JVM to start eprof. Engaging zero preparation
profiling might have a short term impact on application performance as the JVM adjusts to the demands of performing dynamic
measurements.
Subtopics
Synopsis
Synopsis
To profile your application, use:
java -Xeprof:options ApplicationClassName
where
options
is a list of key[=value] arguments separated by commas.
The following options are used in most of the cases:
For CPU time metrics with minimal intrusion:
-Xeprof
Exact call count information and object creation profiling:
-Xeprof:inlining=disable
To see the complete list of available options, use:
java -Xeprof:help
After the profiled application closes, the Java Virtual Machine writes the profile data to a file in the current directory. Use NSjmeter to analyze the file.
—Xverbosegc
The -Xverbosegc option prints out a detailed information about the spaces within the Java Heap before and after garbage collection.
The process ID is automatically appended to the verbosegc file name specified. This helps you to associate a verbosegc output with the
corresponding Java process, especially in cases where an application executes several Java processes.
Subtopics
Synopsis
Synopsis
The syntax of the option is:
-Xverbosegc[:help]|[0|1][:file=[stdout|stderr|<filename>]
NSJ 11 User Guide
79
-Xverbosegc:help for NSJ 11
NOTE:
Parallel and Concurrent GC is available in NSJ 11. Therefore, the -Xverbosegc options pertaining to them are applicable to NSJ 11.
Concurrent GC is deprecated and not supported by Hewlett Packard Enterprise.
-Xverbosegc options
:help prints this message
0|1 controls the printing of heap information:
0 Print after every Old Generation GC or Full GC
1 (default) Print after every Scavenge and Old Generation GC or Full GC
:file=[stdout|stderr|<filename>] specifies output file
stderr (default) directs output to standard error stream
stdout directs output to standard output stream
<filename> file to which the output will be written
n — prevents appending pid to gclog filename
h — appends hostname to gclog filename
u — appends username to gclog filename
d — appends date to gclog filename
t — appends time to gclog filename
At every garbage collection, the following 20 fields are printed:
<GC: %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18 %19 %20>
%1 Indicates the type of the garbage collection.
1: represents a Scavenge (GC of New Generation only)
%2: indicates if this is a parallel scavenge.
0: non-parallel scavenge
n(>0): parallel scavenge, n represents the number of parallel GC threads
2: represents an Old Generation GC or a Full GC
%2: indicates the GC reason:
1: Allocation failure, followed by a failed scavenge, leading to a Full GC
2: Call to System.gc
3: Tenured Generation full
4: Permanent Generation full
5: Scavenge followed by a Train collection
6: Concurrent-Mark-Sweep (CMS)eneration full
7: Old generation expanded on last scavenge
8: Old generation too full to scavenge
9: FullGCAlot
10: Allocation profiler triggered
11: JVMTI force GC
12: Adaptive Size Policy
13: Last ditch collection
3: represents a complete background CMS GC
%2: indicates the GC reason:
NSJ 11 User Guide
80
1: Occupancy > initiatingOccupancy
2: Expanded recently
3: Incremental collection will fail
4: Linear allocation will fail
5: Anticipated promotion
6: Incremental CMS
m indicates the background CMS state when yielding:
0: Resetting
1: Idling
2: InitialMarking
3: Marking
4: FinalMarking
5: Precleaning
6: Sweeping
7: AbortablePreclean
(exited after yielding to foreground GC)
%3: Program time at the beginning of the collection, in seconds
%4: Garbage collection invocation. Counts of background CMS GCs and other GCs are maintained
separately
%5: Size of the object allocation request that forced the GC, in bytes
%6: Tenuring threshold - determines how long the new born object remains in the New Generation
The report includes the size of each space:
Occupied before garbage collection (Before)
Occupied after garbage collection (After)
Current capacity (Capacity)
All values are in bytes
Eden Sub-space (within the New Generation)
%7: Before
%8: After
%9: Capacity
Survivor Sub-space (within the New Generation)
%10: Before
%11: After
%12: Capacity
Old Generation
%13: Before
%14: After
%15: Capacity
Permanent Generation (Storage of Reflective Objects)
%16: Before
%17: After
NSJ 11 User Guide
81
%18: Capacity
%19: The total stop-the-world duration, in seconds.
%20: The total time used in collection, in seconds.
Unsupported tools
jshell
jhsdb
jjs
jps
Websites
General websites
Hewlett Packard Enterprise Support Center
https://www.hpe.com/support/hpesc
Contact Hewlett Packard Enterprise Worldwide
https://www.hpe.com/assistance
Subscription Service/Support Alerts
https://www.hpe.com/support/e-updates
Manuals for L-series
https://www.hpe.com/info/nonstop-ldocs
Manuals for J-series
https://www.hpe.com/info/nonstop-jdocs
For additional websites, see Support and other resources.
Support and other resources
Subtopics
Accessing Hewlett Packard Enterprise Support
Accessing updates
Remote support
Customer self repair
Warranty information
Regulatory information
Documentation feedback
Accessing Hewlett Packard Enterprise Support
NSJ 11 User Guide
82
For live assistance, go to the Contact Hewlett Packard Enterprise Worldwide website:
https://www.hpe.com/info/assistance
To access documentation and support services, go to the Hewlett Packard Enterprise Support Center website:
https://www.hpe.com/support/hpesc
Information to collect
Technical support registration number (if applicable)
Product name, model or version, and serial number
Operating system name and version
Firmware version
Error messages
Product-specific reports and logs
Add-on products or components
Third-party products or components
Accessing updates
Some software products provide a mechanism for accessing software updates through the product interface. Review your product documentation to
identify the recommended software update method.
To download product updates:
Hewlett Packard Enterprise Support Center
https://www.hpe.com/support/hpesc
Hewlett Packard Enterprise Support Center: Software downloads
https://www.hpe.com/support/downloads
My HPE Software Center
https://www.hpe.com/software/hpesoftwarecenter
To subscribe to eNewsletters and alerts:
https://www.hpe.com/support/e-updates
To view and update your entitlements, and to link your contracts and warranties with your profile, go to the Hewlett Packard Enterprise Support Center
More Information on Access to Support Materials page:
https://www.hpe.com/support/AccessToSupportMaterials
IMPORTANT:
Access to some updates might require product entitlement when accessed through the Hewlett Packard Enterprise Support Center. You
must have an HPE Passport set up with relevant entitlements.
Remote support
Remote support is available with supported devices as part of your warranty or contractual support agreement. It provides intelligent event diagnosis, and
automatic, secure submission of hardware event notifications to Hewlett Packard Enterprise, which initiates a fast and accurate resolution based on the
service level of your product. Hewlett Packard Enterprise strongly recommends that you register your device for remote support.
If your product includes additional remote support details, use search to locate that information.
HPE Get Connected
https://www.hpe.com/services/getconnected
NSJ 11 User Guide
83
HPE Pointnext Tech Care
https://www.hpe.com/services/techcare
HPE Complete Care
https://www.hpe.com/services/completecare
Customer self repair
Hewlett Packard Enterprise customer self repair (CSR) programs allow you to repair your product. If a CSR part needs to be replaced, it will be shipped
directly to you so that you can install it at your convenience. Some parts do not qualify for CSR. Your Hewlett Packard Enterprise authorized service provider
will determine whether a repair can be accomplished by CSR.
For more information about CSR, contact your local service provider.
Warranty information
To view the warranty information for your product, see the links provided below:
HPE ProLiant and IA-32 Servers and Options
https://www.hpe.com/support/ProLiantServers-Warranties
HPE Enterprise and Cloudline Servers
https://www.hpe.com/support/EnterpriseServers-Warranties
HPE Storage Products
https://www.hpe.com/support/Storage-Warranties
HPE Networking Products
https://www.hpe.com/support/Networking-Warranties
Regulatory information
To view the regulatory information for your product, view the Safety and Compliance Information for Server, Storage, Power, Networking, and Rack Products ,
available at the Hewlett Packard Enterprise Support Center:
https://www.hpe.com/support/Safety-Compliance-EnterpriseProducts
Additional regulatory information
Hewlett Packard Enterprise is committed to providing our customers with information about the chemical substances in our products as needed to comply
with legal requirements such as REACH (Regulation EC No 1907/2006 of the European Parliament and the Council). A chemical information report for this
product can be found at:
https://www.hpe.com/info/reach
For Hewlett Packard Enterprise product environmental and safety information and compliance data, including RoHS and REACH, see:
https://www.hpe.com/info/ecodata
For Hewlett Packard Enterprise environmental information, including company programs, product recycling, and energy efficiency, see:
https://www.hpe.com/info/environment
Documentation feedback
Hewlett Packard Enterprise is committed to providing documentation that meets your needs. To help us improve the documentation, use the Feedback
button and icons (located at the bottom of an opened document) on the Hewlett Packard Enterprise Support Center portal
NSJ 11 User Guide
84
(https://www.hpe.com/support/hpesc) to send any errors, suggestions, or comments. All document information is captured by the process.
Supported and unsupported features of NSJ11
NSJ11 includes all the features of NSJ 8.0 and it is based on Java OpenJDK 11.0.18.
For information about Java OpenJDK features, see JDK 11 Release Notes
Subtopics
Features not implemented in NSJ11
Nonstandard Java Options
Deviations from Nonstandard Java Options
Features not implemented in NSJ11
Java SE features that do not apply to a server-side HotSpot VM are not implemented in NSJ11.
For information about Java SE features that are not implemented, see following implementation-specific topics:
Headless support
Java Development Kit (JDK)
UseBiasedLocking (JVM internal locking optimization, useful for SMP architectures)
-XX:+TieredCompilation option is not supported
SDP (Socket Direct Protocol)
SCTP (Stream Control Transmission Protocol)
-XX:+UseLargePages option is not supported
-XX:+UseRTMLocking option is not supported
-XX:+UseAVX option is not supported
-XX:+UseBMI1Instructions and -XX:+UseBMI2Instructions are not supported
UseCompressedOops is not supported.
Class Data Sharing (CDS) and Extend CDS is not supported. The following CDS options are not supported:
DumpLoadedClassList
SharedArchiveFile
SharedClassListFile
ExtraSharedClassListFile
UseSharedSpaces
VerifySharedSpaces
RequireSharedSpaces
PrintSharedArchiveAndExit
DumpSharedSpaces
PrintSharedDictionary
SharedBaseAddress
SharedArchiveConfigFile
SharedSymbolTableBucketSize
Nonstandard Java Options
Merged from NSJ11 Tools Reference Pages, place accordingly.
The nonstandard options are:
-Xssn
n -> <n> , provide n in <>
Default Size
NSJ 11 User Guide
85
Min Size
Max Size
For all the options
Sets the thread stack size.
Every thread spawned while a Java program runs has its own stack. This thread stack is shared by Java program code, any native (JNI) code, and the Java VM
code. The default stack size is 512 kilobytes (-Xss512k) . You can use this option to increase the stack size if you experience stack overflow exceptions.
The default units for n are bytes; n must be greater than 1,000 bytes. To modify the meaning of n , append either the letter k (or K ) to indicate
kilobytes, or the letter m (or M ) to indicate megabytes. For example, –Xss10240 and –Xss10k are equal.
Deviations from Nonstandard Java Options
Merged from NSJ11 Tools Reference Pages, place accordingly.
-Xmsn
n --> <n> ,
Default Size
Min Size
Max Size
For all the options
Specifies the initial size, in bytes, of the memory allocation pool. The default value is implementation specific; the value is about 1g.
NSJ 11 User Guide
86