Multi-core hardware increasingly affects the need for multi-threaded application development, which in turn affects the complexity of software. The challenge of, and the need for creating multi-threaded applications will only increase with time.

This trend creates an increasingly prevalent class of software defects, namely thread contentions or concurrency defects that can easily slip the traditional testing techniques resulting in new application quality and security liabilities.

These reliability defects are specifically due to the intermittent nature of the conditions that trigger them. This means that, often, they are not present during the traditional testing phase.

The conditions described above are – deadlock – a state of indefinite wait, and - race condition – a condition of unpredictable results, present when multiple threads are accessing the same memory location in undetermined order, while at least one of these threads is changing the memory location’s content.

Deadlocks are more easily detectable since once an application gets into a deadlock state it stays in that deadlock state. This state then can be analyzed and such analysis is already provided by the JVM. Upon simultaneous pressing of two keys, <Cntl> <Break> (Windows) or , <Cntl> <Back Slash> (Linux), you will be presented with the information on all the threads, including the lines of code involved.

A race condition occurs when two or more threads have simultaneous access to a shared memory location and at least one access is for “Write”.

An access for “Write” is when a thread modifies the value of a memory location. An access for "Read" is when a thread simply obtains the value of the memory location.

The potential for race conditions can be eliminated if all the methods within an application are synchronized. However, all of the benefits of multiprocessing then disappear.

Race conditions are considered to be the hardest software bugs. They are silent and intermittent conditions of unpredictable results. Applications with race conditions are running in a “happy” mode, not crashing, and not generating exceptions or error logs.

Think of it as a net that catches all experienced Race Conditions and does not catch any that are Not a Race Condition (has 0% false positive rate).

False positive analysis results harm productivity by forcing us to spend time and energy in vain. Imagine trying to find a black cat in a dark room when the black cat is not there.

Note: The term false positive (in the case of program analysis an error is reported where no error exist) and in the term false negative” (in the case of program analysis, an error is missed) were first introduced in statistical analysis in the 19th century. (Think of a doctor giving an errant - false positive -diagnosis of some condition to a patient where the condition, in fact, does not exist - and what it does to the patient - and what it does to the doctor’s (in this case tool's) reputation).

Static analysis tools claim around 20% false positives while analyzing race conditions.
During testing, some static analysis tools produced 77% false positives.

Think of it as a net that catches all experienced Race Conditions and does not catch any that are not a Race Condition (has 0% false positive rate).

The only requirement for using SUM4JVM is that the application executes bytecode.

The SUM is designed to operate automatically. This is required for consistently accurate results, wide adoption, and the absence of a learning curve.

In order to be completely automatic, a tool must not require any kind of integration with a specific Interactive Development Environment (IDE).

SUM4JVM is neutral to the environment used to build the application, provided the application is executed by the JVM.

SUM4JVM requires no integration with development environments, alteration or recompilation of existing code – the only requirement for SUM4JVM is that the application executes bytecode.

Since SUM’s complete analysis is done on the bytecode, it does not need the source code to be provided by the user in order to operate. This kind of automation is necessary for two reasons:

• The likelihood of human error, when pointing to wrong source code
• The time and effort required to locate and link the automatically generated project to the original source code.

(with the rare exception when Race Conditions are encoded intentionally.) In such rare cases the reporting of thread contentions is expected.