On 3/9/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
How invasive would this be? Would it be always present or a special build?
Good point. Ilia, can you tell us the impact on behavior/performance of both release build and debug build? Also, you mention some 30 places where there are race conditions. I suspect the tool will show both false alarms as well as missed detections. (Otherwise the technology could be repurposed to solve the Holy Grail of threading -- automatic application parallelization.) If you have a summary of the 30 places, perhaps you can post it. If not, how about posting the entire output of the Thread Checker tool. If its more than 150 lines long, how about putting it in a JIRA unless you think Wiki would be a better place. It would be good to have a discussion on the value of this tool's output. If we are to imbed Thread Checker specific code in drlvm, we need to get an idea how much engineering effort this requires. And who would do this work. And justify this work given there are other, competing demands. I am in favor of tools that help us improve stability. However, the use of Thread Checker is not my decision alone.
-Nathan 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. > > 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? > > > Thanks, > Ilya Leviev > Intel Enterprise Solutions Software Division >
-- Weldon Washburn Intel Enterprise Solutions Software Division
