On 3/9/07, Leviev, Ilia A <[EMAIL PROTECTED]> wrote:
Hi, I have started using http://intel.com/thread_checker_download.zip to find deadlock and race conditions in the VM. First I have checked Harmony which run Hello World Application and tool have detected about 30 race conditions. But on some DRLVM kernel tests it shows several hundred problems. There some problem of tracking Harmony code by the Thread Checker. The reason for this is that the Intel Thread Checker supports interpretation only of standard APIs for Windows and POSIX threading. Any specially built synchronization constructs that are not part of Windows API or POSIX API are not normally tracked by the Thread Checker. However, the Thread Checker includes the User-Level Synchronization API that to help gather information related to user-defined synchronization constructs. Thus if we use our own synchronization we should inform Thread Checker runtime about it. Otherwise the tool will generate incorrect diagnostics and will be useless for us.
Not necessarily useless, it still can be a good assistant tool. My previous experience with Thread Checker did help me discover some real hard bugs.
In other words, to gain full benefit from Thread Checker, the VM developers will need to embed thread checker calls in the synchronization code. Should we put this on the harmony development schedule for Q2?
We need understand what are those "full benefit" DRLVM can get from Thread Checker. And, as a system software, I assume the threading infrastructure will not change dramatically once it's stable. So it would be good if you can summarize the current status of DRLVM when examined with Thread Checker. I guess the current situation as you described is, DRLVM need to be instrumented to really use Thread Checker's assistance. Before that, most of the reported race conditions are false-positive, hence the report is not very useful. We need break the cyclic dependence with reasonable estimation on the potential efforts of the instrumentation and the potential benefits. My personal previous experience with Thread Checker was with parallel application development, or application parallelization in C/C++. I am not sure how Thread Checker can help a threading infrastructure development, esp. when there exist dynamically generated code sequence, and Java app has its own synchronization logic. That being said, I think if the efforts are not huge and the instrumentation doesn't impact much the code base, it would be worthwhile to have a try, since we want Harmony to be rock solid in threading part, any helping efforts should be appreciated, as long as it does help. Thanks, xiaofeng
Thanks, Ilya Leviev Intel Enterprise Solutions Software Division
