You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Leviev, Ilia A" <il...@intel.com> on 2007/03/09 11:40:38 UTC
[drlvm][threading] using a thread verification tool to find deadlock and race conditions
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
Re: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Mar 10, 2007, at 10:40 PM, Xiao-Feng Li wrote:
>
[SNIP]
> 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.
+1
[SNIP]
> 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.
+1
geir
Re: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Posted by Xiao-Feng Li <xi...@gmail.com>.
Thanks, Ilia, for the detailed explanation.
I personally think it's a good idea to make DRLVM work with Thread Checker.
Thanks,
xiaofeng
On 3/20/07, Leviev, Ilia A <il...@intel.com> wrote:
>
> Hi,
>
> "Xiao-Feng Li <xi...@gmail.com> wrote:
> > We need understand what are those "full benefit" DRLVM can get from
> > Thread Checker.
>
> Full benefit - is ability to check threading problems with respect to
> not only standard APIs for Windows and POSIX but also with respect to
> User-Defined (non-standard) Synchronization constructs.
>
> > And, as a system software, I assume the threading
> > infrastructure will not change dramatically once it's stable.
>
> Imbedding of Thread Checker API will not change threading
> infrastructure, it will mark a non-standard synchronization constructs
> without impact on behavior/performance.
>
> Here is example of such marking.
>
> Harmony code contains such non-standard synchronization constructs. For
> example spin lock synchronization functions spin_lock() and
> spin_unlock() in GC_CC at trunk\working_vm\vm\gc_cc\src\gc_types.h file
> are not recognized by the Thread Checker. In order to track this
> synchronization I should mark it by imbedding Thread Checker API
> functions primitives into spin_lock()/spin_unlock() code.
>
> Here is an example of embedding Thread Checker API primitive
> "itt_notify_sync_releasing()" into spin_unlock() function :
>
>
> #ifdef ITCH // build configuration switch
> # include <libittnotify.h>
> #else
> #define __itt_notify_sync_releasing(pAddr) //if ITCH unset, primitive do
> nothing
> #endif
>
> .......................
>
>
> void spin_unlock(volatile int* lock) {
>
> assert(1 == *lock);
> // The releasing primitive of ITCH API
> //tell to ITCH tool that thread will release the lock
> __itt_notify_sync_releasing(&lock);
> *lock = 0;
> }
>
> >So it would be good if you can summarize the current status of DRLVM
> when
> > examined with Thread Checker.
>
> Here is Thread Checker results that have checked Harmony which run Hello
> World:
>
>
>
> _____________________________________________________
> |Component |Number of occurrences|
> |_______________________________|_____________________|
> |jitrino | 25 -data-races |
> |_______________________________|_____________________|
> |vmcore/object | 15 -data-races |
> |_______________________________|_____________________|
> |tm | 3 -data-races |
> |_______________________________|_____________________|
> |vmcore util | 8 -data-races |
> |_______________________________|_____________________|
>
>
> For getting more special result contributors can run Thread Checker on
> intrusting DRLVM component while VM execute some tests intended for the
> component or other application.
>
> >
> > 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.
>
> Non standard sync constructs as described in the above example result in
> false alarms if it wasn't marked. Other results are useful (see JIRA
> H-3425).
>
>
> > We need break the cyclic dependence with
> > reasonable estimation on the potential efforts of the instrumentation
> > and the potential benefits.
>
> During examining DRLVM by Thread Checker I have find place that should
> be instrumented ones. The please is spin lock synchronization constructs
> from GC_CC. So cases were instrumentation will be needed are uncommon.
>
> However if such pleases are instrumented, we will can to test if these
> synchronization constructs can provide thread safe behavior.
>
> >
> > 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.
> >
>
> The purpose of Thread Checker is finding of deadlocks and race
> conditions.
> It helps to make the implementation more thread safe.
>
>
> > 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.
> >
>
> Instrumentation cases will be rarely and will not impact much the code
> base.
> And it will increase a range of DRLVM synchronization mechanisms that
> may be examined by the Thread Checker.
>
> Thanks,
> Ilya Leviev
>
>
>
> On 3/11/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> On 3/9/07, Leviev, Ilia A <il...@intel.com> 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
> >
>
RE: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Posted by "Leviev, Ilia A" <il...@intel.com>.
Hi,
"Xiao-Feng Li <xi...@gmail.com> wrote:
> We need understand what are those "full benefit" DRLVM can get from
> Thread Checker.
Full benefit - is ability to check threading problems with respect to
not only standard APIs for Windows and POSIX but also with respect to
User-Defined (non-standard) Synchronization constructs.
> And, as a system software, I assume the threading
> infrastructure will not change dramatically once it's stable.
Imbedding of Thread Checker API will not change threading
infrastructure, it will mark a non-standard synchronization constructs
without impact on behavior/performance.
Here is example of such marking.
Harmony code contains such non-standard synchronization constructs. For
example spin lock synchronization functions spin_lock() and
spin_unlock() in GC_CC at trunk\working_vm\vm\gc_cc\src\gc_types.h file
are not recognized by the Thread Checker. In order to track this
synchronization I should mark it by imbedding Thread Checker API
functions primitives into spin_lock()/spin_unlock() code.
Here is an example of embedding Thread Checker API primitive
"itt_notify_sync_releasing()" into spin_unlock() function :
#ifdef ITCH // build configuration switch
# include <libittnotify.h>
#else
#define __itt_notify_sync_releasing(pAddr) //if ITCH unset, primitive do
nothing
#endif
.......................
void spin_unlock(volatile int* lock) {
assert(1 == *lock);
// The releasing primitive of ITCH API
//tell to ITCH tool that thread will release the lock
__itt_notify_sync_releasing(&lock);
*lock = 0;
}
>So it would be good if you can summarize the current status of DRLVM
when
> examined with Thread Checker.
Here is Thread Checker results that have checked Harmony which run Hello
World:
_____________________________________________________
|Component |Number of occurrences|
|_______________________________|_____________________|
|jitrino | 25 -data-races |
|_______________________________|_____________________|
|vmcore/object | 15 -data-races |
|_______________________________|_____________________|
|tm | 3 -data-races |
|_______________________________|_____________________|
|vmcore util | 8 -data-races |
|_______________________________|_____________________|
For getting more special result contributors can run Thread Checker on
intrusting DRLVM component while VM execute some tests intended for the
component or other application.
>
> 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.
Non standard sync constructs as described in the above example result in
false alarms if it wasn't marked. Other results are useful (see JIRA
H-3425).
> We need break the cyclic dependence with
> reasonable estimation on the potential efforts of the instrumentation
> and the potential benefits.
During examining DRLVM by Thread Checker I have find place that should
be instrumented ones. The please is spin lock synchronization constructs
from GC_CC. So cases were instrumentation will be needed are uncommon.
However if such pleases are instrumented, we will can to test if these
synchronization constructs can provide thread safe behavior.
>
> 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.
>
The purpose of Thread Checker is finding of deadlocks and race
conditions.
It helps to make the implementation more thread safe.
> 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.
>
Instrumentation cases will be rarely and will not impact much the code
base.
And it will increase a range of DRLVM synchronization mechanisms that
may be examined by the Thread Checker.
Thanks,
Ilya Leviev
On 3/11/07, Xiao-Feng Li <xi...@gmail.com> wrote:
On 3/9/07, Leviev, Ilia A <il...@intel.com> 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
>
Re: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 3/9/07, Leviev, Ilia A <il...@intel.com> 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
>
Re: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Posted by Rana Dasgupta <rd...@gmail.com>.
IIya,
Would it be possible to look at some of the races you have found already
with ThreadChecker? Could you post the report( or the valid section of it
) on the JIRA ?
Thanks,
Rana
On 3/9/07, Leviev, Ilia A <il...@intel.com> wrote:
>
>
> Nathan,
>
> I think we need to introduce additional build configuration switch to be
> able to compile this Thread Checker API calls.
>
> Thanks,
> Ilya Leviev
>
> -----Original Message-----
> From: nbeyer@gmail.com [mailto:nbeyer@gmail.com] On Behalf Of Nathan
> Beyer
> Sent: Friday, March 09, 2007 7:06 PM
> To: dev@harmony.apache.org
> Subject: Re: [drlvm][threading] using a thread verification tool to find
> deadlock and race conditions
>
> How invasive would this be? Would it be always present or a special
> build?
>
> -Nathan
>
> On 3/9/07, Leviev, Ilia A <il...@intel.com> 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
> >
>
RE: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Posted by "Leviev, Ilia A" <il...@intel.com>.
Hi,
Weldon Washburn <we...@gmail.com> wrote:
>Ilia, can you tell us the impact on behavior/performance of
>both release build and debug build?
Weldon, No impact on behavior/performance of both release build and
debug build if switch <ITCH> is unset.
>I suspect the tool will show both false alarms
>as well as missed detections.
False alarms are to be marked in a source code by Thread Checker API.
>If you have a summary of the 30 places, perhaps you can
>post it.
Here is Thread Checker results that have checked Harmony
which run Hello World:
______________________________________________________
|Source code |Number of occurrences|
|_______________________________|_____________________|
|nt_exception_filter_common.cpp | 3 -data-races
|_______________________________|_____________________|
|cg.cpp | 6 -data-races
|_______________________________|_____________________|
|mem_alloc.cpp | 5 -data-races
|_______________________________|_____________________|
|thread_native_thin_monitor.c | 3 -data-races
|_______________________________|_____________________|
|type.h | 3 -data-races
|_______________________________|_____________________|
|hashtable.h | 2 -data-races
|_______________________________|_____________________|
|compiler.cpp | 10 -data-races
|_______________________________|_____________________|
|object_handles.cpp | 15 -data-races
|_______________________________|_____________________|
|drljitinterface.cpp | 3 -data-races
|_______________________________|_____________________|
|thread_ti_others.c | 3 -data-races
|_______________________________|_____________________|
See more detailed description of one compiler.cpp data-races in JIRA
HARMONY-3371.
Thanks,
Ilya Leviev
Intel Enterprise Solutions Software Division
On 3/10/07, Weldon Washburn <we...@gmail.com> wrote:
> On 3/9/07, Nathan Beyer <nd...@apache.org> 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 <il...@intel.com> 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
>
Re: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Posted by Weldon Washburn <we...@gmail.com>.
On 3/9/07, Nathan Beyer <nd...@apache.org> 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 <il...@intel.com> 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
RE: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Posted by "Leviev, Ilia A" <il...@intel.com>.
Nathan,
I think we need to introduce additional build configuration switch to be
able to compile this Thread Checker API calls.
Thanks,
Ilya Leviev
-----Original Message-----
From: nbeyer@gmail.com [mailto:nbeyer@gmail.com] On Behalf Of Nathan
Beyer
Sent: Friday, March 09, 2007 7:06 PM
To: dev@harmony.apache.org
Subject: Re: [drlvm][threading] using a thread verification tool to find
deadlock and race conditions
How invasive would this be? Would it be always present or a special
build?
-Nathan
On 3/9/07, Leviev, Ilia A <il...@intel.com> 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
>
Re: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Posted by Nathan Beyer <nd...@apache.org>.
How invasive would this be? Would it be always present or a special build?
-Nathan
On 3/9/07, Leviev, Ilia A <il...@intel.com> 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
>
Re: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Posted by Weldon Washburn <we...@gmail.com>.
On 3/9/07, Leviev, Ilia A <il...@intel.com> wrote:
>
>
> Hi,
> I have started using http://intel.com/thread_checker_download.zip to
The above download does not work. Where do we find this checker tool?
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