RFR(s): 8149036: Add UL tracing for thread related events at os level

[Thomas Stüfe]

Coleen, Marcus,

thank you for reviewing, and @Coleen, thanks for the sponsoring offer!

Here the latest Webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8149036-add-tracing-for-thread-events/webrev.02/webrev/index.html

As Marcus suggested, I added a new "thread" tag and added the tag to the
logging calls.

btw, I found the command line a bit confusing:

If a logging call is tagged with two tags A and B, I would have thought the
default behaviour of "-Xlog:A" is to log all calls tagged at least with A,
not all calls which are solely tagged with A and nothing else. I could not
even think ot a use case for the latter.

After some searching, I found that the behaviour I want and I would think
makes sense as default is "-Xlog:A*".

This also means that log lines will be mysteriously disappearing from
output if someone adds another tag to that line, unless I always use an
asterix? Or am I just slow to understand the command line syntax?

Kind Regards, Thomas






On Tue, Feb 23, 2016 at 6:52 PM, Marcus Larsson <marcus.larsson at oracle.com>
wrote:

> Hi,
>
> On 2016-02-22 17:54, Thomas Stüfe wrote:
>
>> Dear all,
>>
>> please take a look at this proposed addition to UL. This adds a number of
>> trace points to thread creation. In detail:
>>
>> - it traces thread creation and thread creation errors, including pthread
>> attributes (for Posix platforms)
>> - it traces stack location and creation/removal of stack guard pages.
>>
>> This all was first AIX-only tracing, but I converted this to UL and made
>> it
>> available on all platforms.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149036
>> Webrev:
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8149036-add-tracing-for-thread-events/webrev.00/webrev/
>>
>
> It might be a good idea to add a 'thread' tag and use that in addition to
> the os tag for these messages. It would allow easy filtering of these
> messages for those interested/uninterested. Just 'os' alone is quite a wide
> area.
>
> Thanks,
> Marcus
>
>
> Note also that I added a helper function, os::errno_name(), which is a very
>> simple replacement for strerror() without its problems (thread safety,
>> unwanted localizations...).
>>
>> What do you think?
>>
>> Kind Regards, Thomas
>>
>
>