A decompiler is used to recover the source code from the corresponding byte code. The decompilation is allowed by the tool only in the case of the open source, which is automatically verified as such.
In case of issues found in the proprietary code, users can simply point to their own source code folders. Mapping the issues already analyzed on the byte code to the source code is then done automatically.
Issues Introduced By The Trend Toward Multi-core Computing
Multi-core hardware increasingly affects the need for multi-threaded application development. The challenge of, and the need for creating multi-threaded applications will only increase with time.
This trend will create a higher prevalence of concurrency defects, which can easily slip through traditional testing techniques. The conditions that cause these defects are intermittent, meaning that they may not be present during the testing phase.
The conditions of concern are deadlocks and race conditions. Deadlocks are a state of indefinite wait. Race conditionsare conditions of unpredictable results. These results are present when multiple threads access the same memory location in undetermined order while at least one of the threads is changing the memory location's content.
Race Catcher, from Thinking Software, Inc (TSI), has very specific advantages in comparison with other offerings. The main advantage is in the ability to treat this tool as an addition to your JVM, due to its:
-
Level of automation.
-
General ability to operate as a "Black Box Opener."
-
Absence of "false-positive" results.
-
Low, and additionally configurable overhead.
Level of Automation
Race Catcher works on byte code, eliminating the need for any kind of integration in order to perform the process diagnosis:
-
Eliminating the need to integrate the tool with your development IDE.
-
Eliminating the need to integrate the source code with the tool.
That is you would simply work as you normally do.
In addition, you can configure Race Catcher to publish known issues regarding the multi-threading contentions being observed by Race Catcher. These issues are published to a Message Queue(MQ) and can be picked up anywhere in the world. You have the option to use Thinking Software's message queue as part of your Enterprise subscription, or you can set up your own private MQ Server.
General Ability to Operate as a "Black Box Opener"
A software process does not need to have a threads contention to be diagnosed by Race Catcher and displayed by the Race Catcher UI. One does not need to have access to source code to see the following:
Please see how this view demonstrates the following attributes of any class:
-
All the fields of the class
-
All the methods of the class
-
For each method:
-
All the paramaters
-
All allocations
-
Models of class methods
Deadlocks
A deadlock – a state of indefinite wait – refers to a specific condition where two or more threads are waiting for each other to release a resource, or more than two threads are waiting for resources in a circular chain.
A simple deadlock is where only two threads are involved. For example, Thread-1 waits for Thread-2 to release a lock (Lock2) while Thread-2 waits for Thread-1 to release a lock (Lock1). Neither threads can progress from that state.
More frequently, deadlocks involve multiple threads waiting for resources in a circular chain. An example of this form of deadlock condition can be understood by imagining four cars approaching a four-way intersection in a clock-wise order. Generally, the rule is that the driver on the right has the right-of-way. If the driver who gets to the intersection first waits long enough, the chain closes and another driver will appear to his right. Once all cars get to the intersection, they will be in the state of deadlock until one of the drivers breaks the rule.
When a software application is in a deadlock state, you may suspect that the application is deadlocked only after you become tired of waiting and if you are looking at the screen waiting for a result. The JVM will report the presence of a deadlock only if you press the Ctrl and Break keys simultaneously. NetBeans IDE will diagnose a deadlock and map the problem to the source code automatically, but you must run your application in the debug mode. Running your application in the debug mode is a relatively slow way of executing your code. Additionally, thread contention failures are intermittent, and we cannot expect to catch all of them in the development stage.
Race Catcher automatically diagnoses deadlocks and pinpoints the source code responsible without the necessity of running your code in the debug mode and in a special environment such as NetBeans IDE, and without the necessity to wait and see whether application is going to progress.
Race Conditions
A race condition occurs when more than one thread has simultaneous access to a shared memory location and when 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.
"This situation is an example of a data race (§17.4.5). When code contains a data race, counterintuitive results are often possible."
Sun Microsystems, Inc., Chapter 17, "Threads and Locks," The Java Language Specification, Third Edition, January 2005, http://java.sun.com/docs/books/jls/third_edition/html/memory.html, (October 13, 2009).
NOTE: Race Catcher provides zero percent false positive results in its automatic analysis and pinpointing to the cause of race conditions via intercepting and diagnosing every manifested race condition.
Why dismissing some race conditions as “Benign” can be dangerous
If you search for “benign data races” you will find many research papers on what are “benign” and what are “harmful” races and what different approaches are tried in order to get closer to the truth while getting less “false positives”.
You will run into the following classification of data races commonly used:
-
Harmful race conditions
-
Benign race condition
-
False Positive race conditions identifications
As far as definition of “harmful” versus “benign” data races – we believe that the term “benign” is not really appropriate. What is “benign” today may be “malignant” tomorrow.
By the same token, we believe that the classification of a tool based on how many “harmful” races it finds versus how many “benign” races it finds we believe to be not the best approach. We think it should be instead based on how many “real” races it finds versus how many “false positive race conditions” it finds.
We would rather see the term “allowed data race”, which signifies a data race that was designed to be there, for example in order to generate a random number. Computing is really an exact science, mostly about 0-s and 1-s – not so much “maybe’s”. We believe that race is a race and not-a-race is not a race. If a race is designed to be allowed, it would probably be more appropriate to call it “allowed data race” but not “benign”. The one that is called “benign” is most probably called such because it does not change results in any significant way or the change in results is not significantly important. But what happens when a new addition to a code is built assuming that the code it is based on is deterministic and contains no behavioral uncertainty? The “data race” that was previously ignored as “benign” now may cause serious unpredictability in the result and may become “malignant”.
The Race Catcher approach is in identifying all experienced “real data races” while never falling for “false positives” providing 0% false-positive analysis. It is as simple as 1 is not 0 and 0 is not 1 – black and white – no gray. If a user chooses to classify a race as “allowed data race” it is a user’s choice – only user will know that the race was designed to be there.
Then the classification becomes much simpler
-
race condition
-
allowed race condition
Independent of these discussions, which are still expected to continue, Race Catcher is performing one unquestionably necessary job – positive identification of experienced by an application race conditions.
For more information, please refer to Advantages of Race Catcher.
Race Catcher Editions
Race Catcher comes in several editions and can be used in several ways.
Standard Edition can be used in one of three ways
-
Agent - designed to work without a GUI
-
Standard Editions - designed to work on a stand-alone single server
-
Help Desk Edition - designed to receive issues discovered on other instances
Enterprise Edition is designed to aggregate analysis from:
-
Agents,
-
Standard Editions
And optionally publish it to the remote subscribers
-
Standard Editions
Components
SUM User Interface – allows the user to view the result of the analysis automatically performed during targeted application execution.
Java Agent – Communicates to SUM Analytical Engine dynamic information about your target application.
SUM Analytical Engine – Analyses the information provided to it by the java agent.
Race Catcher Knowledge base (SUM_KB) – Is where the dynamically built knowledge of your application is being stored for later viewing and additional analysis.
Advantages of Race Catcher
What False Positives Do To Us
False positive results harm our productivity. Try to find a black cat in a dark room when the black cat is not there.
False positives reduce our trust in the tool in general.
Static analysis tools claim around 20% false positives while analyzing Race Conditions. In our tests of Static Analysis tools one that is well known produced 77% False Positives.
The best known Dynamic Analysis tools claims 15% – 20% False Positives.
Race Catcher Dynamic Analysis provides 0% False Positive results. And it does not miss any race condition experienced by an application.
Race Conditions
Unnecessary synchronization is doing harm by slowing the application down while obtaining unnecessary locks. That can be seen by imagining the synchronization of all the methods in the application – we would completely loose the effect of multiprocessing.
Race Catcher allows the utilization of collective experience of multiple machines running the same application.
Since Race Conditions are intermittent conditions of unpredictable results, and since applications with race conditions are running in a “happy” (not crashing and not generating exceptions and other logs) mode, utilizing collective experience of applications running in SUM Enabled mode is very helpful.
It allows issues to be addressed before they are experienced by other machines. It also ensure that you do not spend wasted time attempting to verify that a flagged issue is a 'real' race condition.
Building Models of Application Classes
The analysis is done by Race Catcher directly on the byte code and only on active methods of loaded classes. There are many optimizations to keep the overhead reasonable.
The models are built automatically from source code only when they are needed. (automatic de-compilation is done for open source packages that are analyzed.) There is also an option to attach the original source code to the application’s class tree. These will also be automatically built as needed.
The Models are only built when needed, i.e., when there is a need to display the result of the automatically caught and analyzed Race Conditions. The results of the analysis are provided on three views that are tightly connected: the Application’s Class Tree View, The Class Model View, and the Source Code View.
An example of collecting analysis from multiple machines running the same application.
OVERVIEW
The Race Catcher UI provides you with a view of every project that was started in SUM-Enabled mode, i.e. started using the "jta" convenience scripts. "jta" is placed in the script instead of "java" and stands for "Java Threads Analyzer", where SUM stands for the Software Understanding Machine® from Thinking Software, Inc.
In the case of an experienced thread contention, the project will have an icon associated with the contention, i.e. race condition or deadlock, which icon indicates the type of the contention – either an icon of a racing man or a lock icon.
Race Catcher is a JVM runtime analysis tool that automatically identifies and pinpoints experienced thread contentions in byte code when run by a JVM.
The UI component of the product provides the report of the diagnosed contentions. The contentions are displayed being mapped to the source code. Another, synchronized with the source code view, shows the contentions on special animated graphs representing automatically built models of the reported classes and methods.