Use of SSE and SSE2 instructions on IA32 platforms when they
are supported by the processor and operating system.

Faster integer division by constants.

Faster floating-point division by powers of 2.

Faster NullPointerException handling.

Enhancements in J2SE 1.4.1

J2SE 1.4.1 is available in versions that support the 64-bit
Intel Itanium processor on Linux Red Hat 7.2 and Windows XP 64-bit
edition. Look for the downloads for these versions on the J2SE
1.4.1 download
page.

In this release, these 64-bit versions have the following
limitations.

Applications can be run only in interpreted mode. The platform
will run in interpreted mode by default, with no need to supply the
-Xint flag on the command line when launching an
application. When using the 64-bit versions of the J2SE 1.4.1
platform, the command java MyApp will launch and
execute MyApp by interpreting the bytecode. Java
HotSpot-technology-based dynamic compilers for 64-bit support is
planned for a future release of the Java SE platform.

The 64-bit versions of J2SE 1.4.1 do not include the Java
Plug-in and Java Web Start products.

The 64-bit versions of J2SE 1.4.1 do not have an installer
application. These versions are available only as a tar
bundle.

The 32-bit versions of the J2SE 1.4.1 will not work on Intel
Itanium machines.

A deadlock detection utility has been added to the Java HotSpot
VM. The utility is invoked by a Ctrl+\ on the command line while an
application is running. The utility detects Java-platform-level
deadlocks, including locking done from the Java Native Interface
(JNI), the Java Virtual Machine Profiler Interface (JVMPI), and
Java Virtual Machine Debug Interface (JVMDI).

When invoked, the utility displays a thread dump to standard out
and indicates any Java-platform-level deadlocks it detects. Refer
to this sample output. If the
application is deadlocked because two or more threads are involved
in a cylce to acquire monitors, then the list of such threads and
monitors involved in the deadlocks are displayed. Note, however,
that this will not find deadlocks involving threads waiting on
monitors on which no signal will be forthcoming.

Enhancements in J2SE 1.4.0

The new -Xloggc:file option reports on each
garbage-collection event, as with -verbose:gc, but logs
this data to file. In addition to the information
-verbose:gc provides, each reported event is preceeded by
the time (in seconds) since the first garbage-collection
event.

Beginning with J2SDK 1.4.0, the Classic Virtual Machine is no
longer shipped as part of the Java 2 SDK. (On Solaris platforms,
the Classic VM was removed in J2SDK 1.3.0.) If you have been
running your applications on the Classic VM by using the
-classic command-line option, you will need to use either
the Java HotSpot Client VM (invoked by default or by using the
-client option) or Java HotSpot Server VM (invoked with
the -server option). Attempting to launch an application
with the -classic option will result in this message:
Error: Classic VM no longer supported.

The SolarisTM-SPARCTM
platform edition of J2SDK 1.4.0 will support 64-bit operation on
64-bit Sparc-v9 platforms when using the Java HotSpot Server VM.
With a 64-bit address space, more than four gigabytes of heap
memory is available. The Java HotSpot Server VM includes support
for both 32-bit and 64-bit operations, and users can select either
32-bit or 64-bit operation by using command-line flags
-d32 or -d64, respectively.

Users of the Java Native
Interface will need to recompile their code to be able to run
it on the 64-bit VM.

There is no 64-bit support for the Java HotSpot Client VM. Only
the Java HotSpot Server VM provides for optional 64-bit
operation.

Users must install 64-bit Solaris support in order to run the
virtual machine in 64-bit mode.

On older Sparcv9 systems, users must modify the file
/platform/sun4u/boot.conf in order to enable 64-bit
programs. See the text in the boot.conf file for more
information.

The new -Xcheck:jni command-line option performs
additional checks for Java Native Interface (JNI) functions.
Specifically, the Java Virtual Machine validates the parameters
passed to the JNI function as well as the runtime environment data
before processing the JNI request. Any invalid data encountered
indicates a problem in the native code, and the Java Virtual
Machine will terminate with a fatal error in such cases. Expect a
performance degradation when this option is used.