RE: proposal for ICU tracing

Andy,

The problem that I found especially with some ICU code is that some of the
APIs do not even support passing back error codes without some restructuring
and changing APIs.

There is a solution and that is to use thread local storage.  I have
implemented platform independent TLS code in xICU in a way that is
compatible to migrating it to ICU.  http://www.xnetinc.com/xiua/  You can
have the application control tracing at the thread level.  This will keep
the overhead down because in most cases you want to keep your trace to
specific cases.  You also do not want a large trace file to go through.
There are times when applications need to do tracing in production
environments because some problems do not manifest themselves except under
load or in non test suite cases.

The trace could be implemented as a callback to allow applications to put
the trace data into their own trace logs so that they could integrate the
data into a common trace.

If nothing else you could use the trace call back to pass back internal
error codes.

I wasted a lot of time trying to find the cause of some date formatting
errors and had to modify the ICU code but that was difficult to do in a
threaded environment.  If you made TLS available in ICU it would have made
the job easier.  There would be a place to store data until the code could
return to the original ICU API.

Back in ICU 1.4 I requested TLS.  I was modifying ICU to do I/O under the
Apache web server.  However I had no way to pass the file sub-pool pointers
to the I/O routines.  If you provide a call back you may have to pass user
parameters to the callback routine that are thread specific.  To do that you
will need TLS.

You have my permission to use whatever code you may want to use from xIUA.

If you provide new calls to ICU at thread creation / destruction times and
to enable and disable the trace you will just have to have them provide a
callback for trace events.  This will save you from having to develop a
trace logging routine.  This is not an easy thing to do in a platform and
environmental independent way.  The code can assume that if there is no TLS
that there is no tracing.  This is a quick test.  Checking for a trace flag
in the TLS is also low overhead.  For non-threaded environments the code is
compatible because it can use local storage.

Request #2 add a user pointer in the TLS that the application can manage.
Provide an API that makes the address of the pointer available to the
application at any time.  The appliction must free and structures that it
points to with the pointer before freeing the TLS.

I believe that ultimately the addition of TLS support into ICU could
actually improve the performance.  For example it could be used to reduce
locale processing overhead.  ICU spends a lot of processing checking and
decomposing locale information especially when you need both C and C++
locale pairs.  You could save the C locale, a pointer to the C++ locale
object and the language, country and variant components of the locale until
a new locale value was passed.  If the results were stored into TLS they
could speed up ICU processing more than the extra overhead for tracing.  I
have watched traces of ICU activity and believe that this would be a
significant performance enhancement that could be phased in over a few
releases.

Carl



> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Andy Heninger
> Sent: Monday, November 03, 2003 8:55 AM
> To: Robert Buck
> Cc: [email protected]
> Subject: Re: proposal for ICU tracing
>
>
> Robert Buck wrote:
> >>This is a proposal to add a tracing facility to ICU.
> >
> > And of course, may I assume that there will be some
> feature-on/off C preprocessor magic for those of us that do not
> want the runtime overhead?
> >
>
> Yes, some configuration option to compile out the tracing stuff is
> planned.  But, by default, the tracing code will be present in release
> builds.  The overhead is a single if(boolean_variable) test at the entry
>   and exit of traced functions, not too bad.
>
> Initially, our requirement is for tracing of collation API functions.
> Tracing won't be everywhere, at least not at first.  And it wont be on
> every low level internal function, which would indeed result in an
> overhead issue.
>
>
> --
>    -- Andy Heninger
>       [email protected]
>
>
> _______________________________________________
> icu mailing list
> [email protected]
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>