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

Thomas Stüfe thomas.stuefe at gmail.com
Wed Feb 24 09:24:40 UTC 2016

Coleen, Marcus,

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

Here the latest Webrev:

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>

> 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

More information about the hotspot-runtime-dev mailing list